Managing Your OSPF Network | OSPF Network Design Solutions

Table of Contents

As you can see, there are quite a few MIBs available. The good news is that they are all compiled using ASN.1, so they can be compiled and used by any NMS. The difference between managed objects and devices will be discussed in the next section.

Managed Objects

A managed object (sometimes called a MIB object, an object, or a MIB) is one of any number of specific characteristics of a managed device. Managed objects are composed of one or more object instances, which are essentially variables. There are two types of managed objects, which are defined as follows:

• Scalar objects. These objects define a single object instance.

• Tabular objects. These objects define multiple related object instances. These instances are grouped together in MIB tables.

An example of a managed object is OSPFIFMETRICTABLE, which is a scalar object. It contains a single object instance, in this case it is the metric associated with a router interface running OSPF.

Additional OSPF MIB information is provided later in this chapter in the section, “OSPF MIBS.”

Object Identifiers

An object identifier (or object ID) uniquely identifies a managed object in the MIB hierarchy. The MIB hierarchy can be depicted as a tree, with a nameless root, the levels of which are assigned by different organizations. Figure 9-12 illustrates the MIB tree.

Figure 9-12 The MIB tree.

The top-level MIB object IDs belong to different standards organizations, and lower-level object IDs are allocated by associated organizations.

Vendors can define their own private branches that include managed objects for their own products. MIBs that have not been standardized are typically positioned in the experimental branch.

The managed object OSPFIFMETRICTABLE can be uniquely identified either by the object name:

    iso.identified-organization.dod.internet.mgmt.MIB-2.OSPF.    ospfifmetrictable

or by the equivalent object identifier descriptor:

1.3.6.1.2.1.14.8

It is important to note that the textual name as shown is not used but rather the OID (that is, the string of numbers) is what is used to identify the data requested.

TIPS:
Refer to Figure 9-12 to understand and see how each branch or segment of the MIB tree provides a number. When you reach the desired “leaf” MIB, the object descriptor has been derived as a series of numbers describing your path to that specific MIB.

MIBs and SNMP Interactions

MIB variables are accessible via the Simple Network Management Protocol (SNMP), which is an application-layer protocol designed to facilitate the exchange of management information between network devices. As previously described, the SNMP system consists of three parts: SNMP manager, SNMP agent, and MIB.

Instead of defining a large set of commands, SNMP places all operations in a GETREQUST, GETNEXTREQUEST, GETBULKREQUEST, and SETREQUEST format. For example, an SNMP manager can get a value from an SNMP agent or store a value in that SNMP agent. The SNMP manager can be part of a network management system (NMS), and the SNMP agent can reside on a networking device such as a router. You can compile a MIB with your network management software. If SNMP is configured on a router, the SNMP agent can respond to MIB-related queries being sent by the NMS. The SNMP agent gathers data from the MIB, which is the repository for information about device parameters and network data. The agent also can send traps, or notifications of certain events, to the manager. Table 9-1 describes the SNMP manager operations.

**Table 9-1** SNMP Manager Operations
Operation	Description

`GETREQUEST`	Retrieves a value from a specific variable
`GETNEXTREQUEST`	Retrieves the value following the named variable. Often used to retrieve variables from within a table.
`GETRESPONSE`	The reply to a `GETREQUEST`, `GETNEXTREQUEST`, `GETBULKREQUEST`, and `SETREQUEST` sent by an NMS
`GETBULKREQUEST`	Similar to `GETNEXTREQUEST`, but fills the `GETRESPONSE` with up to `MAXREPETITION` number of `GETNEXT` interactions
`SETREQUEST`	Stores a value in a specific variable.
`TRAP`	An unsolicited message sent by an SNMP agent to an SNMP manager indicating that some event has occurred.

With the GETNEXTREQUEST operation, an SNMP manager does not need to know the exact variable name. A sequential search is performed to find the needed variable from within the MIB.

TIPS:
The Cisco trap file, mib.traps, which documents the format of the Cisco traps, is available on the Cisco host ftp.cisco.com/pub/mibs. The SNMP manager uses information in the MIB to perform the operations described in Table 9-1.

Managing a Network with MIBs

This section introduces polling on Cisco routers. In addition to the specific router MIB variables that are recommended here, this information could also apply to other network devices (hubs, switches, hosts, end stations, and so forth). Just substitute MIBs that the devices support for the router MIB variables. There are three kinds of polling, which are described as follows:

• Monitor Polling. Determines the availability of devices.

• Threshold Polling. Detects error conditions.

• Performance Polling. Analyzes data for trends or performance measurements.

Monitor and threshold polling are functions of the management platform. Questions about configuring, debugging, and interpreting them should be directed to the platform vendor.

Monitor Polling

Monitor polling detects network changes and generates immediate alarms. These changes are “hard errors,” like a device not responding or an interface status change. Any alarm generated by monitor polling should be acted on immediately. If your Network Management System is monitored around the clock, a monitor polling alarm should create a visible and audible alarm on the system, so the operator can take immediate action. If your Network Management System is not always monitored, a monitor polling alarm should send an alarm to the appropriate person, possibly via pager or e-mail.

Table of Contents