Smarter MIBs

MIBs represent a shared name space between SNMP agents and managers. They allow an operator to leverage the management facilities deployed in the network. Because of their central role in network management, MIBs should be as well written as possible. The following MIB notes provide some guidelines.

Our MIB notes are primarily intended to promote NE manageability (one of the four M's mentioned in the preface). High levels of NE manageability offer a number of benefits:

• The NE is easier (and cheaper) to incorporate into a network and an NMS.

• The specific NE features are easier to access and manage.

• End- user confidence levels are raised with regard to the vendor.

• The NE acquires a degree of product differentiation.

The enterprise networking market is highly competitive with tight margins. If a given NE is easy to install, configure, and operate in an NMS environment, then that is a considerable advantage for the vendor. If the NE feature set (e.g., MPLS, Frame Relay) is easy to access (via both the EMS and SNMPv3), then the cost of integration and ownership are reduced. Happy end users are likely to upgrade or purchase new equipment. All of these are good things from the vendor's perspective, particularly in an industry where NEs are increasingly similar. We now describe some aspects of MIBs that improve manageability.

MIB Note: Avoid MIB Object Semantic Dependencies

A surprisingly difficult thing to do in SNMP is create new rows in MIB tables. The problem lies in having to understand the semantic relationships between the table columns . If a table (such as the MPLS tunnel table from Chapter 3) has, say, 37 columns, then not all columns have to be set in order to create valid entries. Loose coupling between columns is a good thing because the user knowledge burden is lower. A good way of coupling together blocks of related MIB objects is to provide multiple tables (similar to relational database normalization). This is particularly so when the tables can be reused (e.g., as in the MPLS tunnel hop table for EROs and the MPLS tunnel resource table for bandwidth reservations . These two tables can be reused by many tunnels, so by not including their objects in the tunnel table, the overall data set is less redundant).

Additional tables can then be linked into the parent table using integer indexes. The external tables can then be shared (e.g., more than one tunnel instance can share the same ERO).

Where intercolumn relationships do exist, this should be indicated clearly in the MIB using comments.

MIB table column semantic dependencies complicate provisioning code because the NMS software has to understand the columnar relationships. Another problem is that they also complicate the database schema when the columnar relationships have to be duplicated . The latter point illustrates the problem of modeling the NE MIBs in the NMS. Since the NMS must track the state of the NEs, it has to store NE data usually in a relational database. It is in the schema of the latter that it is often required to duplicate the MIB data. Intercolumn MIB dependencies make for a more complex database schema.

MIB Note: Provide Default MIB Object Values

Providing default values for all MIB table objects is useful for facilitating a thin provisioning code layer. In other words, the caller provides specific values for the required MIB table columns and relies on defaults for the rest. When the NMS request arrives at the provisioning code layer, all the data can be simply written to the associated NE MIB objects with little need for checking. In other words, default values help simplify network- facing code.

Default values can be given to extraneous MIB objects (column objects that are not needed in a given SNMP operation), for example, mplsTunnelIncludeAffinity in the MPLS tunnel table. This object is used when creating a tunnel in which the user wants to constrain the signaling path through an MPLS cloud so that it uses only a specific type of interface on each hop. This type of tunnel may reflect a higher (or lower) class of service reserved for certain end users ”in short, much of the time, this type of tunnel may not be required, so the mplsTunnelIncludeAffinity object will, in many cases, not be set. Providing a default value for this and similar objects can help to prevent agent exceptions caused by the insertion of bad values; these can occur if the sender inadvertently uses an invalid value for a given column but the agent tries to interpret the value anyway and generates an exception. This guideline indicates that only mandatory columns are set; the rest are given safe, default values.

To illustrate this, the allowed values of mplsTunnelIncludeAffinity are integer bitmasks ; each bitmask represents an interface color code value, for example, 0x00001 for gold, 0x00010 for silver, and 0x00100 for bronze. The network operator must configure these colors on all NEs where color selection will be used. In Chapter 3, Figure 3-3, the nodes LER A, LSR D, LSR E, LSR F, and LER B could be configured to support the colors silver and bronze on their ingress interfaces. Then a tunnel could be created with a path constrained to use only interfaces with the colors silver and bronze by setting mplsTunnelIncludeAffinity to 0x00110. The tunnel so created would follow the path described. This is another example of traffic engineering, where the path is reserved in advance by special actions on the part of the network operator.

A sensible default value for mplsTunnelIncludeAffinity (and its associated objects) could be 0 to indicate non-use of this MIB object. Since the default provisioning value has been chosen to match the MIB default value, there is no need to validate before updating the MIB. This reduces the size of the provisioning code layer. New MIBs should always be written to include default values for all objects.

MIB Note: Centralize MIBs to Match NE Features

A good example of a centralized feature is the MPLS tunnel table. Most of the tunnel-related content is located in this table. This avoids the need for expensive MIB walks in order to manage tunnels. The single table allows for tunnels to be created, modified, monitored , and deleted ”in other words, full management using just a few interrelated MIB tables. This helps to keep provisioning code (and connection discovery code) simple and avoids the need for the simultaneous loading of multiple MIB files in the NMS .

This is similar to solution engineering considerations. MIBS should be structured so that solution components are clearly expressed and easily accessed. Again, the MPLS tunnel table is a good example because it illustrates the main MPLS managed objects (such as tunnels, EROs, and resource blocks) in a fairly clear and concise manner.

Issues like the above MIB notes provide good reason for the developers of NMS maintaining the MIBs to work in close cooperation with the NE developers. In other words, authority and responsibility for MIBs should be shared between the main interested engineering parties. Poor-quality MIBs can result in unnecessarily complex NMS software and possibly even NEs that are difficult if not impossible to properly manage.