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.
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:
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.