MIB Support Features

MIBs are the cornerstone of SNMP-based NMS. They provide details concerning the network managed objects and form the basis for the NMS data model. In an ideal world, the MIBs would be sufficiently flexible to provide the bulk of the data model, but (as discussed in Chapter 3) for the current generation of MIBs, this is generally not the case. NMS should provide a number of baseline features for MIB support, including the ability to:

• Load new MIBs in addition to the existing set

• Support multiple versions of the same MIB

• Unload MIBs no longer in use

• Browse and analyze MIBs

When new devices are added to networks, their associated MIBs must be loaded into the NMS in order to provide managed-object access. It should be a relatively simple matter of adding new MIB files to the existing set. The new MIB files should be automatically compiled by the NMS and verified for correctness. Following the addition of the files, the associated managed objects should then become visible to the NMS. This latter would almost certainly be a manual configuration step, but the inclusion of marked objects could help in automating it, as described next .

MIB Note: Principal Managed Objects

Mandatory managed objects in a MIB should be clearly indicated and marked for easy inclusion in an NMS . These MIB objects reflect the core management features supported by a host NEs, and ease of inclusion facilitates importing new NEs into existing managed networks. (This point was made in the preface).

If the mandatory objects are marked (or tagged), then this can also facilitate automatic parsing. A sample marking could be a simple MIB comment like "--M" placed just before the mandatory object with "--/M" just after it. Coupled with default object values, this serves to improve the device manageability. The MPLS MIBs already include this with MODULE-COMPLIANCE clauses. RFC 2580 provides useful SMIv2 conformance guidelines; for example, related objects can be indicated using the OBJECT-GROUP macro.

It was mentioned in Chapter 1, "Large Enterprise Networks," that not all NEs deployed in a network will necessarily host the same firmware version. In some cases, later firmware revisions may require extra memory or even special-purpose hardware. This reflects the ongoing problem of feature cram as NEs become more complex. Denser NEs require more RAM, flash, and more powerful processors to support higher levels of intelligence. So, it is a fact of life that a given network operator may not have a common firmware revision on all its NEs. Since the MIB set is generally compiled into the executable firmware image, it follows that there may then be numerous versions of the same MIB deployed in the network. This adds up to a broader range of managed network objects. The NMS must be able to support all deployed MIB versions. Providing this support can be difficult, particularly when (as is often the case) there exist substantial differences between the various MIB versions. MIB authors (and implementers) can greatly reduce the burden on NMS developers and users by following guidelines such as those in RFC 2578. Examples of the latter include the DESCRIPTION clause and not using reserved keywords (some MIB compilers may not complain about reserved keywords),

Where entire MIBs have been deprecated or the associated managed objects are no longer in use, it is useful to be able to retire them from the NMS. This helps to free up resources and can take the form of unloading the relevant MIB files ”the reverse process of manually loading MIB files.

NNM MIB Support Features

NNM supports the loading of both standard and third-party MIBs. This helps in extending NNM to support additional and modified existing NEs. As long as all MIB objects have unique object identifiers, it is also possible to support different versions of the same MIB. Unwanted MIBs can be unloaded as required. NNM also allows operators to browse and graph managed objects from any loaded MIB. This can be done either in real time or historically.