Network Topology Autolayout Errors

NNM will occasionally draw part of a network topology that varies with what you know is correct. This is NNM’s way of telling you that it is having some sort of difficulty and is making the best of a bad situation. NNM is very conservative. It tends to make few assumptions and will retain old data that once was accurate over new data that is inconsistent or inconclusive. Usually, this is not a bug with NNM, and by exploring the circumstances surrounding the discovery and layout problems, the reason is almost always found. The remedy may not be as apparent.

Sometimes NNM doesn’t lay out part of the network properly because it cannot get the information it needs from a buggy SNMP agent. For example, an Ethernet switch may not properly implement the bridge MIB, so NNM isn’t able to correctly identify all of its ports. The discovery problem leads to an autolayout problem.

Since NNM tends to hang on to old configuration information, it may have difficulty when a device configuration radically changes. For example, inserting a new card into an Ethernet switch and restarting it often results in renumbered MIB instances for the ports. At the next configuration check, NNM may add all the new instances in but not delete the old ones. Sometimes the only way to rid the NNM database of this stale data is to delete the device and then ping it from the NNM system to force a rediscovery. Note that since maps won’t be affected by this until they are opened, the map count for this deleted object will be inconsistent.

NNM’s IP-centric design will create a subnet container for every subnet it discovers. If a router interface has one primary address and three secondary addresses, then NNM will show the router as having four subnets attached. This is completely true from an IP viewpoint. Suppose that the additional subnets are needed to support an increasing number of devices. Each device discovered is situated into its proper subnet container. Now suppose that the switches are assigned IP address at random from the available four subnets. NNM will draw the physical topology in each subnet incorrectly, as shown in Figure 13-1. The fix is to readdress the switches to the same subnet. In this subnet, NNM will be able to correctly draw the physical topology. If some of the switches are addressed within the same subnet, they will be connected properly, but their peers will be lodged within the other subnet icons, ruining NNM’s ability to lay out the correct topology.