Keeping the Knowledge Base Current

If a knowledge base is not accurate, its usefulness quickly degrades. Several techniques can help keep the information current.

The first technique is to establish procedures for documenting network changes in your knowledge base. To make this work, you probably want to allow the engineers and technicians in your network access to change the knowledge base. There should be an easy way to change the data and some way of logging what was changed and by whom. The procedure to enter these changes should enhance the likelihood that it will be used. These changes should be recorded during or right after the change to the network is made. Web-based interfaces may enhance the ability to record changes quickly, easily, and from any point in the network.

You will also want to implement a procedure to verify changes. Even with change-tracking procedures in place, your knowledge base will be subject to the "creeping crud syndrome." Errors will be introduced, either through incorrect data entry or through changes that were not documented. Therefore, it is important to periodically survey the network in order to correct any errors in your knowledge base. Some things can be checked using automatic procedures; other things will require someone to physically inventory your network. The following sections cover aspects for which you can automate checking.

Layer 2 and Layer 3 Connectivity

With some types of layer 2 topology discovery, such as the Cisco Discovery Protocol (CDP) or other techniques, you can determine the layer 2 topology of your network. Using this information, you can verify connections between any two devices. Note that CDP will show only Cisco devices and will not show intervening non-Cisco devices.

If you are keeping topology information in your database, you can utilize some sort of automated discovery to track changes to this topology. This will allow you to verify topology information independently of your network engineers or technicians updating the network documentation and knowledge base.

Device Connectivity

Using information collected from the bridge table combined with ARP and reverse name resolution (DNS, etc.) allows you to determine which devices are attached to which ports on your switches. This information is referred to by some network management packages as user tracking data. If you have standardized on some type of naming convention, it may be possible to determine which types of devices are connected to which ports and then verify or correct information in your knowledge base.

Another way to determine ports that may be interesting is to watch for ports that have more than one MAC address associated. In all probability, these ports support more than one user and should probably be monitored for availability.

Verifying Interesting Ports

If you consistently find ports that are up and have a high level of traffic passing, yet your knowledge base declares these ports as "uninteresting," it may be time to re-evaluate those ports.

Detecting Redundancy

If ports are discovered to be in the spanning tree blocking status, they are redundant links. This information can be obtained from the bridge MIB. If your knowledge base does not reflect this information, it will not be able to correctly associate the priority of outages on this port and the port or ports it is redundant with.

If you are using a protocol such as HSRP, you may be able to verify that your knowledge base contains information about this redundancy by parsing the configuration files from your routers.

Name Resolution

With the information provided by a name resolution system such as DNS, you can verify that the devices and associated IP addresses in your knowledge base match the information returned by name resolution, with both forward and reverse lookups.

Verification of Device and Port Configuration

You can verify the information in your knowledge base by polling devices for the protocols supported, or associated interfaces or ports. For example, it is possible that devices that did not have SNMP capabilities have been upgraded to support SNMP or have had SNMP enabled.

Polling for the speed of an interface (MIB II ifSpeed) and comparing to the thresholds stored in your knowledge base may allow you to detect unreasonable threshold values. Typically, the volume of events generated will detect values that are too low, but hysteresis may suppress most of these. This method should be effective in detecting high thresholds or misconfigured bandwidth statements in the configurations of network devices.

As performance reports are analyzed, inaccuracies may be detected in your network knowledge base. It could be that changes have been made to your network and not recorded, or the way the network is being used has changed. It should be easy for network administrators to update the knowledge base when such inaccuracies are detected.

The most accurate way of keeping your knowledge base up-to-date is to make critical functions rely on the information in your knowledge base. For example, if the list of devices in your knowledge base is used to create your Domain Name System (DNS) tables, it is likely that someone will attempt to contact a new device through its name and, if the knowledge base doesn't have this information, they will report the deficiency. Any technique that you can use to link operational procedures to your knowledge base will significantly increase the accuracy of your knowledge base.