Setting Up RMON


Remote monitoring, or RMON, is another method similar to SNMP to track statistics on interfaces or ports on network devices. The RMON feature typically is utilized in a LAN switch environment but is available on the access routers (for example, 2x00 Series) in IOS 11.1 or higher. It may only be required to set up RMON on remote routers when you cannot get access to the LAN equipment, such as hubs, to view the traffic. RMON does not require you to actively poll for SNMP variables on a regular basis. The devices store the information needed, and then it is dumped periodically to an RMON network management station. Please refer to "Remote Monitoring MIB and related MIBS" in Chapter 8 for more details on the RMON functionality. For the purpose of this "best practice," we'll focus on the switch configuration, assuming a switch is at a remote access site in addition to the router, sharing a common LAN segment.

RMON is easily enabled on a switch by using the CLI command set snmp rmon enable. When RMON is enabled, the supported RMON groups for Ethernet ports, as specified in RFC 1757 are

  • Statistics

  • History

  • Alarms

  • Events

When RMON is enabled, the supported RMON groups for Token Ring ports, as specified in RFC 1513 and RFC 1757, are

  • Mac-Layer Statistics

  • Promiscuous Statistics

  • Mac-Layer History

  • Promiscuous History

  • Ring Station Order Table

  • Alarms

  • Events

RMON gets more interesting when you define the rising and falling alarm thresholds for the Alarm and Event groups, as well as turning on Statistics and Histories. Granted, the raw data collected is still valuable, but thresholding allows you to watch things a bit more closely. These threshold settings normally are configured by a remote monitoring application via SNMP and not from the command-line prompt. Cisco and other vendors provide applications to perform these functions. We'll first go through the methodology on when to do what task, and then we'll look briefly at the MIBs needed to enable the appropriate RMON group.

There are several steps that should take place prior to actually implementing thresholds using the Alarm and Event groups. The first step of baselining the traffic flows in your network to understand the patterns, for example, is the traffic local, cross-campus, or campus-to-Internet. Using SNMP or even RMON probes and applications, gather statistics about the environment, such as EtherStats from the Statistics RMON group or the Histories. After a baseline is performed, you should identify critical ports on the switches, like switch trunk ports (ISL or 802.10 based) or file server ports. You should then analyze the normal characteristics associated with those ports by trending the data. Given the normal characteristics, you can start to define alarm thresholds.

After the alarms have been defined and refined, you no longer need to actively poll for traffic statistics as frequently because the device can monitor itself through the use of RMON events and alarms. The purpose for polling now would be solely for historical or availability reasons and not for fault monitoring.

You can continue to use RMON Histories for the whole switch to gather statistics for the RMON application if you don't want to use up network bandwidth for constant SNMP polling. An RMON probe for critical ports such as trunks also can continue to poll the EtherStats over time to see what is happening in the switch.

The MIBs needed to set RMON Alarms and Events as well as define the History characteristics originate from RFC 1757. Refer to this RFC for the MIB specifics or "Remote Monitoring MIB and Related MIBs" in Chapter 8 for more RFCs relating to RMON.



Performance and Fault Management
Performance and Fault Management: A Practical Guide to Effectively Managing Cisco Network Devices (Cisco Press Core Series)
ISBN: 1578701805
EAN: 2147483647
Year: 2005
Pages: 200

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net