Managing Your OSPF Network

Previous Table of Contents Next

Today, SNMP is the most popular protocol for managing diverse commercial internetworks, as well as those used in universities and research organizations. SNMP-related standardization activity continues even as vendors develop and release state-of-the-art, SNMP-based management applications. SNMP is a relatively simple protocol, yet its feature set is sufficiently powerful to handle the difficult problems presented when trying to manage today’s heterogeneous networks.

Introduction to SNMP

Until the early-to-mid 1990s, the management method used for these two devices depended upon SNMP-compatible management platforms offered by the hardware vendors. They provided remote configuration of the devices, alarm capabilities for minor and major alarms, and network mapping. All provided benefits to network managers who no longer had to configure a device on site or look at the LEDs for alarms. Network management could now be controlled via a centrally located administration package compatible with industry-standard SNMP.

SNMP, in both agents and clients, is based on Management Information Bases (MIBs). MIBs (defined in detail in the section, “The Management Information Base”) can be standards-based, complying with those written for particular applications to collect statistics or track information on a wide variety of networking activities. These MIBs are publicly available to any manufacturer to incorporate into its products.

Proprietary MIBs are those written by a particular manufacturer to track either specific network anomalies, such as bandwidth utilization, or to track particular device activity, such as packet discards.

These MIBs are the sole property of the manufacturer and might or might not be made available to other companies. MIBs are typically created to make a company’s own devices or network management software product more valuable to the end users.

SNMP does have drawbacks, however. Most SNMP capability is embedded in network devices like hubs, routers, FRADs, DSU/CSUs, and switches. These devices primarily pass or route data. Although they can provide snapshots of the network at intervals ranging from five to thirty minutes via SNMP get request. commands issued by the network manager, they have neither the processing power nor the memory capacity to store real-time data for any length of time. This does not enable you to see what is going on in your network 100% of the time; instead, you have to piece together snapshots. If you want to see everything going on, you need to consider adding a device (that is, specialized server or poller) specifically designed to fulfill this requirement. Another way of achieving this it through your Network Management System (NMS), which is discussed in the next section.

Network Management System (NMS)

The Network Management System (also known as the manager) is software that has the capability of operating on one or more workstations. This software can be configured so it can be utilized to manage different portions of a network or multiple managers can manage the same network. The manager’s requests are transmitted to one or more managed devices on the desired network. These requests are sent via TCP/IP. SNMP is not dependent upon TCP/IP for transport across a network. SNMP has the capability to be transported via numerous other transport mechanisms such as Novell’s NetWare IPX and various other transport protocols. Though as previously mentioned, this book concentrates on the TCP/IP implementation. You can specifically define the NMS as follows:

  An NMS executes applications that monitor and control managed devices. They provide the bulk of the processing and memory resources required for network management. One or more NMSs must exist on any managed network.
  The network manager has a few commands at his/her fingertips to get information from a managed device. These commands are GETREQUEST, GETNEXTREQUEST, and SETREQUEST. Because SNMP is based on the utilization of the TCP/IP transport protocol, to issue any SNMP command the manager must have the IP address of the destination agent.
  The manager issues the GETREQUEST command to an agent (discussed in the next section). This command may be utilized in one of two ways; it can be used to view a single MIB variable, or a list of MIB variables from the destination agent.
  The GETNEXTREQUEST command is similar in nature to the GETREQUEST command. However, when the agent receives the particular request, it attempts to retrieve the next entry in the MIB for the identified managed object. To use an example, if the manager were to issue a sequence of the GETNEXTREQUEST commands to a managed object, the manager has the ability to “browse” through that managed object’s MIB. Thus, a series of GETNEXTREQUEST commands can be used to read through a row with the incrementation of the values for the requested managed object and see how quickly the packets are processing, or perhaps keep on eye on critical failure marks.
  The final manager-based command is the SETREQUEST command. This command is similar to the previous two in one way; the network manager issues it to a defined agent. The SETREQUEST command requests the agent set the value of an individual instance of a managed object—these are variables stored at a device—or instances contained in the command. The SETREQUEST command is only successful if the network manager can write to the managed object. If the managed object is read-only, the command will fail since the value of the managed object instance could not be amended.


An agent is a network management software module that resides in a managed device. It has local knowledge of management information and translates that information into a form compatible with SNMP.

To be a managed device, each device must have firmware in the form of code. This firmware translates the requests from the SNMP manager and responds to these requests. The software, or firmware, not the device itself, is referred to as an agent. It is possible to manage a non-SNMP compatible device, but they must support a proprietary management protocol.

In order to support a non-SNMP compatible device, you must first obtain a proxy agent. This proxy agent acts as an interpreter because it translates the SNMP requests into the proprietary protocol on the non-SNMP device.

Previous Table of Contents Next

OSPF Network Design Solutions
OSPF Network Design Solutions
ISBN: 1578700469
EAN: 2147483647
Year: 1998
Pages: 200
Authors: Tom Thomas

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: