Network Management

Although the call model provides a good estimation for initial deployment, you must monitor the network and quantify real-world utilization after the deployment is complete. Performance monitoring should encompass the same factors as the call model, plus traditional router health metrics. These metrics are not covered here but should include CPU and memory utilization. Performance monitoring is an important tool for network planning, but a comprehensive network management strategy also needs to encompass fault management.

Centralized fault management in Mobile IP is generally limited to the health and availability of Mobility Agents. Some capabilities for user monitoring are available, but because Mobile IP is an edge-intelligent routing protocol, the Mobile Node is the ideal to place to begin troubleshooting when something goes wrong. Remote management in the situation is not possible because the node is usually unreachable. The Simple Network Management Protocol (SNMP) is an ideal and established tool for networking and is ideal for monitoring and managing Mobile IP agents. Specific management objects related to Mobile IP are discussed in the sections that follow, but you should also monitor nonMobile IP objects such as Hot Standby Router Protocol (HSRP) and AAA, when those services are in use.

RFC 2006 Management Information Base (MIB)

RFC 2006 provided the original definition of management objects for Mobile IP. The objects in the RFC 2006 MIB provide detailed counters that are related to the basic features and error message in the original definition of Mobile IP in RFC 2002. Objects that you should watch include the registration acceptance and failure counters. How these objects are used depends largely on the overall management strategy and is generally beyond the scope of this book. Fault management systems should look at failed registrations and analyze specific error codes to help determine minor failures with individual nodes from systemic problems. Performance management with the RFC 2006 MIB should include monitoring registration rate by evaluating the number of registrations over a given monitoring interval.

Cisco Enterprise MIB

The RFC 2006 MIB has some significant shortcomings when dealing with modern Mobile IP implementations. Management of Mobile Nodes identified by NAI is difficult because the NAI is not part of the original MIB and, as such, must be translated to the Home Address externally. Proposals to update the RFC 2006 MIB have been made, but to date, no new standard has been adopted. In the interim, Cisco IOS has adopted an enterprise-specific (vendor-specific) MIB. Most of the features of this MIB are part of the proposed update to RFC 2006, but it also includes a few objects that are specific to the Cisco IOS implementation of IOS Mobile IP. The biggest feature is the ability to reference Mobile Nodes by NAI rather than just Home Address.

Support for Home Agent redundancy counters has been added, along with specific information related to the performance of the Home Agent. One key performance management statistic that was lacking from the RFC 2006 MIB was the ability to determine the number of Mobile Nodes currently using the Mobility Agent. This information could be computed by counting the number of entries in the binding and visitor tables, but for Mobility Agents with tens to hundreds of thousands of Mobile Nodes, this was a significant use of resources. The Cisco Mobile IP MIB has objects to determine the number of active bindings and visitors with just one query.

NOTE

A graphical representation of the objects available in both MIBs is available in Appendix B, "IOS Mobile IP: Supported SNMP MIBs."

Objects Matching the Call Model

The four scaling areas discussed in the section "Scaling Issues," earlier in this chapter, should be monitored closely and can be evaluated using the following management objects:

• Total number of Mobile Nodes From the Cisco Mobile IP MIB, the cmiHaRegTotalMobilityBindings and the cmiFaRegTotal visitors objects give the total number of bindings on a Home Agent and visitors on the FA, respectively.

• Frequency of Mobility From the RFC 2006 MIB, the haRegRequestsReceived and the faRegRequestReceived should be monitored, and the change of polling interval should compute the registration rate. You can also compare these to haRegistrationAccepted and faRegRequestsRelayed, respectively, to determine the error rate. If the received rate is not the same as or close to the accepted/relayed rate, the object for the specific error codes should be evaluated to determine where failures are.

• Amount of data traffic Data traffic should be monitored using the standard IOS interface traffic objects.

• Number of tunnels The number of active tunnels can be monitored using the ifNumber object from the RFC 2863 interface MIB. This includes the total number of interfaces on the box, which you can compare against the maximum number of supported IDBs.

System Log Messages

As a general practice, system messages should be logged to a remote syslog message server for offline processing. Few Mobile IPspecific error messages exist, but all of them are documented under IPMOBILE in the IOS system messages guide for the specific IOS release. The most common error message is the security violation message. Older releases of IOS generate a security violation message with type 131 when the clocks are out of sync. This is common and is a self-recovering condition, as described in Chapter 3, "Mobile IP Security." New versions of IOS no longer generate syslog error messages for type 131 errors.