Knowledge Base Tools

You learned in Chapter 3, “Developing the Network Knowledge Base,” that a knowledge base helps consolidate the data that you maintain about your network. As shown in Figure 9-1, it is the central piece in your NMS. Although we show one central knowledge base in this figure, the information that makes up your knowledge base can be implemented in many ways, and parts of it may reside in each of your NMS tools.

You will probably use a mixture of tools and techniques to implement a knowledge base. You can use the information stored in several commercially available tools that have a database and tie them together using scripts or tools you develop or buy.

Alternatively, you may choose to implement a central repository for your knowledge base that you can use to feed all of your network management tools. Most NMS frameworks and tools have interfaces or APIs (application programming interfaces) that allow you to integrate these tools into your network-management strategy. You may choose to make use of “glue” programs or scripts to combine the various tools you use into a whole by using your knowledge base as the core.

As mentioned in Chapter 3, developing and using a knowledge base generally requires programming capabilities such as script writing and database design. Various applications provide the capability to collect and maintain some network-related data. Through integration, data exchange, and some programming, you can work toward a common knowledge base.

Some people may feel intimidated by the thought of knowledge bases and custom programming, but if you can clearly formulate and articulate your needs, you can design a system that meets your needs. It may be that no commercial system can do this for you. And programmers can make fine resources to develop well-defined “glue” programs or scripts.

The way you collect the information and the way you store it will depend upon the tool(s) you select to manage your network. For example, you may choose to use a tool that collects information about your network through its auto-discovery feature. You may also use its database as your knowledge base. However, you may find that the tool has limited means for customizing its data for your purposes.

Instead, you can extract the information collected by such a tool and combine it with your knowledge of your network. From the data and knowledge, you can then produce a knowledge base that is tailored to your environment. Automating the task of data collection and coordination tasks can make the tasks more maintainable and easier to update.

The following criteria should be considered when evaluating tools that may contribute to your knowledge base (once again, more important criteria for knowledge base tools are placed higher on the following list):

• The key capability for your knowledge base is data exchange. To be successful in using a common knowledge base, there must be robust ways to share this information across your network management tools.

• It may be important to have your knowledge base accept dynamic updates and be able to push out these changes to all tools that use the updated knowledge. An example of this would be your NMS framework running auto-discovery. It discovers a new network device and adds it to the knowledge base. It would be desirable for your performance management and reporting tools to automatically start collecting data and reporting on this new device.

• You may want to be able to access this information through your choice of tools, whether they are Excel, PERL scripts, or whatever. This will allow you to generate custom reports or ad hoc queries, as well as provide a way to interface tools that don't directly allow data exchange or support different protocols for data exchange.

See Chapter 3 for details on how a knowledge base might be structured. Bear in mind that you want to develop a schema that can accommodate the growth and change in your network.

In addition to flat files, spreadsheets, and databases, some of the following tools are useful, either as a central repository or as contributors to the knowledge base:

• Aprisma Spectrum—either as a contributor or as a repository

• Computer Associates Unicenter TNG—either as a contributor or as a repository

• Cisco CiscoWorks 2000 Resource Manager Essentials Inventory—as a contributor of detailed device inventory knowledge

• Cisco CiscoWorks 2000 Campus Manager User Tracking—as a contributor of end node Layer 2 connectivity information

• Hewlett Packard OpenView Network Node Manager—either as a contributor or as a repository

• SAS Institute, The SAS SYSTEM—as a repository

• Tivoli NetView—either as a contributor or as a repository

• Visionael—as a repository

Here is an example of how to take advantage of the knowledge contained in an application and integrate it with your network knowledge base.

The user-tracking portion of Campus Manager provides a wealth of information about end nodes in a network, including the following:

• MAC address

• IP address

• Host name

• Switch and board and port on the switch it's connected to

• VLAN and the VLAN type the device is in

• VTP Domain the switch is a member of

• Date/time when this node was last seen on the network at this location

This last item is especially useful for tracking hardware utilization of your network equipment, such as tracking the ports on your switches that are currently in use and how many free ports are available. It can also be used to track the usage of IP addresses, so unused ones can be reassigned. Note that the node-related date/times that most NMS frameworks have are not related to the Layer 2 location in the network in which the device is currently located, so the two can be used together to provide a richer set of capabilities.

User tracking also supports the capability to have the user annotate fields with username and notes, which could be used to store custom data of pretty much any type. Unfortunately, there is not an easy method to programmatically insert data into these fields.

User tracking includes facilities for searching and exporting this information from a GUI interface as well as exporting the data from the CLI. You could export this data as a comma-separated file or through XML, and then import it into your knowledge base.

This knowledge then could be used in the following way:

• User tracking will discover not only the MAC addresses, but also the host names of devices if you have name services configured.

• If you have all your servers configured using some sort of name (such as Server1, etc.), your knowledge base will give you the information about what switch ports your servers are connected to.

• Then, you could monitor the usage on these ports by using your event configuration tool to set up thresholds on each of these ports.