4.2. SNMP approach

The previous section looked at the topology of a network at layer three of the OSI network model. As has been shown, detecting layer three devices is fairly straightforward since these devices alter the packets that are transmitted on the network. Layer two devices, however, do not make any changes to packets on the network. As a result, these devices are essentially transparent, making them impossible to detect using the techniques described in Section 4.1.

To understand how to go about detecting layer two devices on a network, one first needs to understand something about these devices. Devices that operate at the datalink layer typically come in two forms: managed and unmanaged. Unmanaged devices simply plug into the network and operate as is — they are not configurable in any way.

Managed devices, on the other hand, are configurable in some way. Typically, these devices bind their own IP address and are network addressable, meaning that they can be remotely configured. Vendors are free to choose the means and protocols that are used to configure these devices, but for reasons of inter-operability, these devices usually contain an embedded SNMP agent. These SNMP agents can be addressed using the MIB-II, meaning that a large proportion of the information available from them is available in a standardised form.

Two of the metrics that are standardised in MIB-II are the interface and IP tables. These tables contain, amongst other things, a list documenting which MAC addresses (interfaces.ifTable.ifEntry.ifPhysAddress) and IP addresses (ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaIfIndex) are associated with each interface on the device. The information contained in these two tables can be used to determine where a particular device is located on the network. By making some assumptions about the entries in these tables, a layer two topology map can be built.

On any layer two device, one has a number of interfaces. On each of these interfaces, one can have a host or another network device, in other words, a leaf or a node on a graph. Since these devices are transparent on the network, the difficulty lies in deciding whether each interface is connected to a leaf or to another node. Some progress can be made by assuming that any interface that has only one MAC address or IP address associated with it, is a leaf of the graph. This is a reasonable assumption since computers typically only have one network card and one IP address.

The problem lies in deciding what to do with interfaces that have multiple entries. For example, computers that function as web servers often have multiple IP addresses associated with them. Fortunately, it is reasonably rare for these computers to use more than one network card on a particular network, meaning that they only have one MAC address associated with them. In the same way, computers that use IEEE 802.3ad link aggregation to connect several network cards to a single network typically use one MAC address shared between all aggregated network cards. From this, one can assume that any interface that has both multiple MAC addresses and multiple IP addresses is a node, and any interface that has just one MAC address or one IP address associated with it is a leaf.

Once there is a way of separating nodes and leaves on the graph there is the further problem of determining the IP address of the managed layer two device that forms the node. There are two approaches that can be used to solve this: either some seed information can be provided about which devices on a specific network are network devices or the graphing application can attempt to make an intelligent decision about what devices are network devices.

While the first of these approaches is by far the simplest, the latter is not as complex as it might at first seem. The Institute of Electrical and Electronics Engineers (IEEE) maintains a list of Organizationally Unique Identifiers (OUIs). These OUIs form the first twenty-four bits of every MAC address, and are used to identify the manufacturer of the device [IEEE, 2002]. To a large extent, vendors that make network devices such as managed switches do not make network cards, and vice versa. Those vendors who manufacture both types of devices tend to have multiple OUIs (Cisco Systems, for example, have registered 192 OUIs), and use a different OUI for each class of device.

If the graphing application is provided with a list of OUIs that are known to belong to network devices, it can use this information to intelligently decide which of the devices on a network should be considered to be layer two devices, and thus represented as nodes on the graph. It can further use this information to work out the IP address of each node, which it can use to recursively query each node for its interface table.

Based on these assumptions, a layer two network mapping application was written. This application again used the GraphViz graphing engine. This application was used to plot a topology map of the Computer Science Department's network (this smaller network was chosen because it had a known topology, allowing the accuracy of the results to be determined). Seed information about the layout of the network was provided using an XML-based configuration file as described in Section 3.2. The results of a run of this application is shown in Figure 4-4.

Figure 4-4. Layer two topology map of the Computer Science Department

In Figure 4-4, the pentagons represent layer two network devices, the squares represent computers on the network, the oval in the center represents the up-link to the rest of Rhodes' network and red lines represent up-links between switches.

There are two abnormalities in this graph that are worth noting; eth2.coe.ru.ac.za is a layer two switch that is shown on the map to have no hosts attached for it. This apparent lack of leaves occurred because at the time this map was generated, the SNMP agent on that node was not running. The result is that all the leaves that should be rendered as attaching to eth2.coe.ru.ac.za are shown as attached to nne12.cs.ru.ac.za.

rucus is shown on the map to be a computer, but has another computer, kaos attached to it. This layout is correct; rucus has two network cards in it and acts as a bridge (using FreeBSD's bridge(4)) between kaos and the rest of the network.

The biggest problem with the approach taken in this section is that it does not scale well. While it was known that the approach would never work on the scale of the Internet, it was assumed that the method could be used to represent a reasonable sized campus network. An attempt was made to graph the whole of Rhodes' campus using the SNMP method outlined above. The graph produced had an order of magnitude more hosts on in, and took just under two hours to lay out and render. Unfortunately the rendered graph was completely illegible, which made it useless as a representation of Rhodes network. Clearly another way needed to be found to represent information about a network of this magnitude. Chapter 5 looks at another, more successful approach.