A significant problem facing most network administrators is that of keeping track of where computers are located on a network. This location is both physical and logical — physical as in what room the machine is located in, and logical as in to which switch port a host is connected. This information is part of the configuration management area in the OSI network management model. Knowing the location of a computer is important when trying to diagnose network faults, especially when the fault can be seen to originate from a particular machine.
Traditionally, this problem has been solved by maintaining meticulous records of all movements of computers and changes in network cabling. These records can be refered to in order to determine where a particular network component should be, either logically or physically. Unfortunately, records such as this are seldom adequately maintained. The result is that as networks evolve, less is known about how the various components that form the network are interconnected. This is particularly true of networks that develop in an ad hoc manner.
This phenomenon is best illustrated by a news story that appeared on several reputable wire services in April 2001. When an equipment audit was conducted at the University of North Carolina in the United States, it was discovered that one of their Novell servers was missing. While the computer was working and visible on the network, nobody knew where it was physically located. An extensive search revealed that the server in question had been sealed behind a dry wall a number of years earlier [TechWeb, 2001].
While most cases are not as extreme as the one at the University of North Carolina, the problem of locating machines is certainly one that exists in a large number of networks. It is a problem that also exists within Rhodes, so once again, Rhodes provided a useful case study in which to experiment with a solution to this issue.
As was observed in Chapter 5, Hamilton Building (housing the Departments of Computer Science and Information Systems) was constructed in 2001 and fully occupied in January 2002. A new building presents an ideal opportunity for getting things right, and indeed, during the construction phase, detailed records were kept of all network installations. As is typical with a new building, there was a settling in period after the two departments moved in, and during this time many changes were made to the network infrastructure. Records of these changes are sketchy at best, leading to the sort of situation that was described above.
The logical location of a computer can be worked out by tracing network cables back from the computer to the switch that it is connected to. This is a tedious and time consuming way of finding out how a network is interconnected, and ideally would only be done when a new network point is installed. A software solution would be far more convenient, and would allow records to be more easily updated and maintained.
While software solutions are feasible for managed switching infrastructure, they are impossible for unmanaged network devices. This is because, in an unmanaged network, there is no way of associating a switch port with a computer other than physically checking which cable is plugged into which port. For this reason, this section will only look at managed network infrastructure.
The SNMP MIB-II specifies a way of retrieving an address resolution protocol table from a network device. On an OSI layer two network device, this ARP table contains an association between a network interface controller's MAC address and the interface on the device through which that network interface controller is visible. Entries in this ARP table have a limited lifespan and are refreshed every time traffic is directed at a host that is connected to the device. On a managed network device, an SNMP agent on the device can be used to read this table.
All computers connected to an Ethernet network maintain their own ARP tables. Unlike layer two network devices, devices at layer three or above that use the Internet Protocol (IP) maintain ARP tables associating MAC addresses with IP addresses. This ARP table contains, at a minimum, every host on the local subnet which has recently engaged in communication. Again, ARP entries have a limited lifespan and are refreshed every time traffic is sent to another host. Those hosts that are beyond the subnet boundary do not have an entry in the ARP table — a single entry for the default gateway is maintained instead.
These two bits of information can be combined to provide a correlation between a specific host on the network and a switch port.
In order to ensure that there is a valid entry for the host in the monitoring machine's ARP cache, it needs to generate some traffic to that host. This can be as simple as a single ICMP echo request or ARP whois request to the host. The arpwatch(8) program automates this to a large extent. Once this has been done, the monitoring machine's ARP table can be queried to determine a MAC address for the host. Using the SNMP MIB-II, this MAC address can be looked up in the switch's ARP table to determine to which interface the host is connected.
This works very well for networks where there is a single switching device. Unfortunately, real world networks tend to have significantly more than one switch — Hamilton Building, for instance, has thirteen switches serving over four hundred network points.
The algorithm for determining which interface on which particular switch a host is connected to is a little more complex. First of all, it is necessary to have some idea of the topology of the network. This can either be manually configured or automatically learned (as in Section 4.2).
Given a set of switches serving a particular subnet, the interface that a host is connected to can be determined by first querying any one of the switches to determine on which interface the host's MAC address can be seen. This query will give the interface on the queried switch that serves the host in question. It can be determined from topology information if the interface in question is a trunk port (an uplink or a downlink to another switch) or whether the interface serves the host directly. If the switch serves the host directly, the search terminates and the interface is known.
If, however, the interface on the queried switch is a trunk, the search moves to the switch providing that trunk. The process of querying the ARP table to determine which interface the MAC address is visible on is repeated on this new switch. This continues until an interface is found that provides direct connectivity to the host in question.
Since this is effectively a search tree, the number of switches that needs to be queried can be minimised by starting at the root of the tree. This root should either be the switch that has the most trunks attached to it or the core switch (usually a layer three switch providing virtual LAN (VLAN) capabilities). Experimentation will show which is the best root of the search for those cases where the switch with the most trunks is not the core switch. This is probably an uncommon situation though.