6.4. Shortfalls

There were two problems experienced with this system, one technical and one social.

Nortel equipment forms the majority of the switching infrastructure in Hamilton Building. At the core of the network are thirteen Baystack 450 switches stacked together to form three separate switch stacks. Each of these stacks runs its own SNMP agent that serves all the switches in that stack. All three of the stacks are running identical versions of the Nortel firmware on identical hardware. They are also all configured in a common way.

For some indeterminable reason, the SNMP agent on one of these switch stacks is unstable. It operates perfectly when the stack is first powered on, but over time it starts failing to respond to some SNMP get requests. The original solution to this problem was to simply re-send the request until such time as a valid SNMP response was received. However, the performance degrades over time until it reaches a point where it simply stops responding to queries at all, making this approach useless. It seems that once this has happened, the only solution is to power cycle the switch stack. The other two switch stacks operate entirely as expected. Unfortunately, the stack that displays this erratic behaviour is the stack for which this application would prove most useful — it is the stack that provides connectivity to staff machines.

It should be noted that the interface ARP tables that this application uses come out of MIB-II, which means that they should be standardised across vendor platforms. As such, the application should not differentiate between different makes and models of devices. Nevertheless, Section 3.2 provides a solution to any vendor-specific quirks should they arise.

Socially, it is difficult to convince the end users of the need to gather this information. Although it takes under two minutes to complete the process, a test run with some post graduate students showed that less than a third of the people asked actually took the time to enter their network point number. This issue can be solved to a large extent by user education.

The bigger problem is that the students who did take the time to complete the process were concerned about the amount of information that was known about their location prior to their completing the form. In other words, the pre-population of the database gave people the impression of a "big brother" type application. This feeling of being watched may explain why other people were reluctant to complete the process.

There are two different solutions to this issue. The first is to simply not pre-populate the database. This would require that people entered more information about their computer and increase the amount of time taken to gather the data (especially from shared workspaces where there is common information between a number of end users). The second is, once again, user education. The process of pre-population needs to be carefully explained to people in such a way that they understand that its function is to make it quicker and easier for them to enter the specific details of their machines.