Future Network Considerations | OSPF Network Design Solutions

Table of Contents

Configuring Alarms and Events: New in 11.1(2)

In 11.1(1) you needed an RMON console (such as Netscout) to configure alarms and events. Starting in 11.1(2) you can do it on the command line. However, these commands are not documented in 11.1 manuals yet. These commands are available in any 11.1 image, not just the special 2500 RMON images. They enable you to set a threshold on any numeric MIB variable (not just RMON MIB variables) and generate an SNMP trap or other event when the threshold is crossed.

To configure alarms, you need to enter the following:

    rmon alarm <alarm-number> <MIB object> <interval> { delta |absolute }    rising-threshold <rising-value> [<event-number>] falling-threshold    <falling-value> [<event-number>] [owner <owner>]    no rmon alarm <alarm-number>

To configure events, you need to enter the following:

    rmon event <event-number> [log] [trap <community>]    [description <description>] [owner <owner>]

Assume, for example, that you need to configure RMON to generate a trap if CPU utilization reaches or exceeds 60 percent, and rearm the trap if utilization drops to 40 percent or less. The sampling interval is 20 seconds. You would need to enter the following:

    rmon alarm 1 lsystem.56.0 20 absolute rising-threshold 60 1    falling-threshold 40 2 owner me    rmon event 1 log trap public description "cpu busy" owner me    rmon event 2 log description "cpu not too busy"

For another example, assume you need to configure a 2500 series router to send a trap and log an event when the alarm threshold, on monitoring its own ifInOctets (ifEntry.10.1), exceeds an absolute value of 90000. The monitoring is done every 60 seconds and the falling threshold is 85000. In this case, the Netview management station received a trap: router.rtp.cisco.com: A RMON Rising Alarm: Bytes received exceeded threshold 90000; value=483123 (sample type=1; alarm index=10). You would need to enter the following:

    snmp-server host 171.68.118.100 public    snmp-server community public RO    rmon event 1 log trap public description "High ifInOctets" owner jdoe    rmon alarm 10 ifEntry.10.1 60 absolute rising-threshold 90000  1    falling-threshold 85000 owner jdoe

Keep in mind that you can enter the MIB to be a threshold as a full dotted-decimal value (such as, 1.3.6.1.2.1.2.2.1.10.1) in which case the box converts it (to ifEntry.10.1, in this case).

To get to the bottom line, the command-line syntax for adding events to a router is as follows:

    rmon event <#> {<log><trap>} <community> <description<string>><owner>    rmon alarm <#> <mib-variable> <interval-seconds> { delta | absolute }    rising-threshold <mib_value> <num_event_tofire> falling-threshold    <mib_value> <num_event_tofire> <owner>

For a final example, look at the following code:

    rmon event 1 log trap public description "Rising Event for bufferFail"    owner admin    rmon event 2 log trap public description "Falling Event f/bufferFail"    owner admin    rmon alarm 1 lsystem.46.0 30 delta rising-threshold 5 1    falling-threshold 5 2 owner admin

SNMP Versus RMON

These days, corporate MIS departments typically get fewer resources while facing daunting challenges. Consequently, networking engineers have a difficult time staying current with new releases of products in their network and keeping up with new technologies. However, what are the best technologies available for your network?

That question can be answered in several different ways depending upon your thoughts. It is a basic truth of a healthy and well-performing network that network managers and engineers need better tools with a standards-based architecture.

One basic fact is that SNMP and RMON are both being used to determine network health and performance. This section will attempt to give an objective view of them both while comparing and contrasting each. This information will enable you, the network manager, to make the correct decisions for your network.

These observations ring true, but often go unheard. In order to prove these thoughts on what can be termed “a business,” refer to International Data Corporation’s June, 1997 report, “Managing Data Overload,” which cites three industry trends driving network monitoring:

• The increased deployment of switched topologies

• The increased use of Web-based computing

• The enterprise’s requirement to establish service-level contracts with their carriers

The report further contends, “The combination of RMON with network element management software products is integral to end-user network management strategies.”

Regarding revenue potential, it continues, “Network element management software represent . . . a $250.4 million opportunity in 1997 and will grow to $482.6 million in 2001. Interlinked with this device-driven management market is RMON instrumentation and reporting, an $827.3 million market in 1997.”

SNMP and RMON: Network Management Standards

The first standard for network management evolved into a specification that became known as Simple Network Management Protocol (SNMP), based upon the TCP/IP protocol stack, and was given RFC number 1098 by the Internet Engineering Task Force (IETF). By embedding SNMP within data communication devices, multivendor management systems can manage these devices from a central site and view information graphically. However, there are significant limitations to this important standard. SNMP allows devices to be polled regularly, but it does not provide for extensive proactive monitoring of critical functions or the monitoring of network traffic on a LAN segment. SNMP-based devices will only identify traffic specifically addressed to itself and cannot provide statistics on “conversations” between devices, an important concept for network troubleshooting.

RMON1, developed by the IETF (Internet Engineering Task Force), became a standard in 1992 as RFC number 1271 (now RFC 1757). The RMON specification was developed to provide traffic statistics and analysis on many network parameters for comprehensive network fault diagnosis, planning, and performance tuning. RMON delivers seamless multivendor interoperability between SNMP management stations and monitoring agents. RMON provides a standard set of MIBs, which collect rich network statistical information not available from SNMP. Finally, RMON allows proactive network diagnostics via its powerful Alarm Group, which lets users set thresholds and receive automatic alarms for threshold violators.

Table of Contents