Configuring RMON

This chapter describes how to configure remote network monitoring (RMON) on the ML-Series card for the ONS 15454 SONET/SDH.

RMON is a standard monitoring specification that defines a set of statistics and functions that can be exchanged between RMON-compliant console systems and network probes. RMON provides you with comprehensive network-fault diagnosis, planning, and performance-tuning information. The ML-Series card features RMON and is designed to work with a network management system (NMS).

Note For complete syntax and usage information for the commands used in this chapter, see the "System Management Commands" section in the Cisco IOS Configuration Fundamentals Command Reference, Release 12.2.

Note For general information about using Cisco IOS to manage RMON, refer to the "Configuring RMON Support" chapter of theCisco IOS Configuration Fundamentals Configuration Guide.

Understanding RMON

RMON is an Internet Engineering Task Force (IETF) standard monitoring specification that allows various network agents and console systems to exchange network monitoring data. You can use the RMON feature with the Simple Network Management Protocol (SNMP) agent to monitor all the traffic flowing among ML-Series card and other switches on all connected LAN segments.

Enable history collection for the specified number of buckets and time period.

•For index, identify the RMON group of statistics. The range is 1 to 65535.

•(Optional) For bucketsbucket-number, specify the maximum number of buckets desired for the RMON collection history group of statistics. The range is 1 to 65535. The default is 50 buckets.

•(Optional) For intervalseconds, specify the number of seconds in each polling cycle. The range is 1 to 3600. The default is 1800 seconds.

•(Optional) For ownerownername, enter the name of the owner of the RMON group of statistics.

Step 4

end

Return to privileged EXEC mode.

Step 5

show running-config

Verify your entries.

Step 6

show rmon history

Display the contents of the ML-Series card history table.

Step 7

copy running-config startup-config

(Optional) Save your entries in the configuration file.

To disable history collection, use the no rmon collection historyindex interface configuration command.

This example shows how to collect and show RMON history for the owner root:

ML_Series(config)# interface gigabitethernet1

ML_Series(config-if)# rmon collection history 2 owner root

ML_Series(config-if)# end

ML_Series# show rmon history

Entry 2 is active, and owned by root

Monitors ifIndex.393217 every 1800 second(s)

Requested # of time intervals, ie buckets, is 50,

SONET/SDH Alarms, GFP Defects, and CRC Errors

The POS ports on the ML-Series card report alarms for SONET/SDH defects and GFP defects, including signal fail (SF) and signal degrade (SD) alarms. In most circumstances, these alarms alert the user to problems that also cause excessive CRC errors on the POS port. But there are situations where excessive CRC errors will occur on the POS port, but the link will not have any SONET defects or GFP defects to report. Examples of this situation include an ML-Series card at the other end of the link sending out packets with CRC errors or a bit error rate too low to trigger SF or SD defect, but high enough to cause a meaningful CRC packet error rate.

In these situations with a default ML-Series card RPR implementation and no reported SONET/SDH or GFP defects, the POS interface remains in the up state as a member of the shared packet ring (SPR) interface. Traffic is lost quietly and does not trigger any alarms or action.

Configuring ML-Series Card RMON for CRC Errors

The ML-Series card supports using an NMS for SNMP performance monitoring (PM), including monitoring cyclic redundancy check (CRC) errors. If the NMS supports periodic polling and programmed threshold values to monitor interface index errors (ifInErrors) for all the ML-Series card interfaces, you can manage and monitor CRC errors by relying on the NMS.

If the NMS does not support polling or if the desired polling frequency uses too much bandwidth, you can configure SNMP traps on the ML-Series card through the Cisco IOS CLI. This method is only for ML-Series cards on the ONS 15454 SONET/SDH. RMON capabilities for ML-Series cards on the ONS 15310-CL and ONS 15310-MA are best managed through Cisco Transport Controller (CTC), Transaction Language One (TL1), or Cisco Transport Manager (CTM) in the standard manner for the node.

Configuration Guidelines for CRC Thresholds on the ML-Series Card

These are the guidelines for determining the interface CRC errors (ifInErrors) threshold values for generating an NMS PM alert:

•SONET/SDH bit errors also create POS CRC errors. There is no alarm suppression hierarchy between the SONET/SDH errors and POS errors, so each set of errors creates separate alerts.

•The actual packet rate of an interface is unpredictable. A high bandwidth interface might forward only a few packets per minute in a particular time period of low data traffic, which means a relatively low number of CRC errors would represent a 100 percent loss. A lower bandwidth interface might forward a high packet count (millions) per minute during a particular time period, and so a relatively few CRC errors would represent an error rate of 10-9. This situation prevents the straightforward determination of a maximum bit error rate (BER), which is often used for non-packet-based PM.

•You can set up the monitoring of ML-Series card CRC errors for either signs of minor trouble or signs of major trouble. For minor trouble monitoring, set a relatively quick and sensitive error rate trigger, such as 10 errors in a 60 second period. This method will likely generate an NMS alert every time an interface goes up or down, a fiber error occurs, or a SONET/SDH protection event occurs (even though protection might occur within 50 ms). To monitor only major trouble and to reduce the number of alerts, set a relatively high threshold, such as 1000 errors in a 300 second period.

Accessing CRC Errors Through SNMP

CRC errors for each interface are reported in the IF-MIB object ifInErrors (OID 1.3.6.1.2.1.2.2.1.14). Users can check the current value of ifInErrors through SNMP get requests. Each ML-Series card runs a separate instance of SNMP. SNMP requests are relayed to the individual ML-Series card based on the community string. The community string uses the following format:

com_str_configured_from_CTC@ml_slot_number

ifIndex Operation in the ML-Series Card

ifIndex mapping is saved to the TCC2/TCC2P database so a replacement card also receives the same mapping. However, the ifIndex mapping is only saved with the IOS CLI command copy running-config startup-config.

The ifIndex mapping is cleared when an external startup-config file is uploaded for the ML-Series card slot using a non-Cisco IOS management interface, including the startup-configuration file upload feature of CTC, CTM, and TL1. ML-Series card resets with no stored ifIndex mapping may re-assign ifIndex values. This is important when deployment configurations are created offline and uploaded to the node through the startup-config upload feature. The ifindex mapping may also be lost during upgrades or downgrades of the system software. SNMP requires that all interface ifindex values be persistent (do not change) once established, even after configuration changes and ML-Series card resets.

To force persistent ifindex values in Cisco IOS, the mapping from interface to ifindex must be saved whenever the configuration is saved, and restored after a reset. This is not done by default. To enable persistent snmp ifindex values, the following Cisco IOS CLI command must be entered and then saved to the startup configuration.

Global configuration command: [no] snmp-server ifindex persist

Example:

Router(config)# snmp-server ifindex persist

Router(config)# copy running-config startup-config

When this command is enabled and the new configuration is saved, this will also store the interface to ifindex mapping to the TCC2/TCC2P cards.

Configuring an SNMP Trap for the CRC Error Threshold Using Cisco IOS

The ML-Series card supports RMON trap functionality in Cisco IOS. You must use the Cisco IOS CLI to configure RMON to monitor ifInErrors and generate a trap to an NMS when a threshold is crossed. The ML-Series card on the ONS 15454 SONET/SDH does not support the configuration of RMON traps through an SNMP set request, which typically initiates an action on a network device.

Beginning in privileged EXEC mode, follow these steps to configure RMON to monitor ifInErrors and generate a trap for an NMS when a threshold is crossed:

The ifIndex number of an ML-Series card interface in decimal formused for the rmon alarm command in the example is ifInErrors.983043. This variable is the MIB object to monitor combined with the ifIndex number of an ML-Series card interface. For information on determining the ifIndex number for an ML-Series card, see "Determining the ifIndex Number for an ML-Series Card" section.

Below is an example of a rising-threshold trap generated by 1002 ifInErrors crossing a threshold of 1000 in a 5-minute period.

2005-03-22 16:25:38 ptlm9-454e56-97.cisco.com [10.92.56.97]:

SNMPv2-MIB:sysUpTime.0 = Wrong Type (should be Timeticks): 43026500

SNMPv2-MIB:snmpTrapOID.0 = OID: RMON-MIB:risingAlarm

RFC1271-MIB:alarmIndex.9 = 9

RFC1271-MIB:alarmVariable.9 = OID: IF-MIB:ifInErrors.983043

RFC1271-MIB:alarmSampleType.9 = deltaValue(2)

RFC1271-MIB:alarmValue.9 = 1002

RFC1271-MIB:alarmRisingThreshold.9 = 1000

SNMPv2-SMI:snmpModules.18.1.3.0 = IpAddress: 10.92.56.97

Determining the ifIndex Number for an ML-Series Card

When an NMS polls an ML-Series card for performance data, the NMS uses ifIndex numbers internally to consolidate interface data from multiple MIBs and associate this data with an interface name. The user can rely on the interface name and does not need to know the actual ifIndex number.

When you use the Cisco IOS CLI to configure the ML-Series card to generate traps directly, you do not have this associated name to use. You must use the actual ifIndex number for each interface being configured with a trap. To determine the actual ifIndex number, you can use an NMS to retrieve the ifIndex number of each ML-Series card interface and VLAN subinterface, or you can calculate the ifIndex number for the interface.

The user can also use a MIB browser (SNMP MIB definition lookup service) to examine the ifDescr for the appropriate ifIndex number. The ifIndex number from the ifDescr must be the ifIndex number for the desired port.

On an ML-Series card, the ifIndex number of Ethernet and POS interfaces is compiled from two pieces of information:

•The chassis slot number of the card—The slot number is the number of the physical space in the shelf that the ML-Series card resides in. It ranges from Slot 1 to Slot 6 or Slot 12 to Slot 17 on an ONS 15454 SONET/SDH shelf. You can find this information in many ways, including through the graphical representation of the shelf slots on CTC, or by looking at the front of the physical shelf.

•A local port number within the card—Port numbers of the ML-Series cards for the ONS 15454 SONET/SDH match the interface numbers for Fast Ethernet and Gigabit Ethernet interfaces. POS port numbers do not match the interface numbers and do not consecutively follow the Ethernet port numbering. A consecutive value is skipped between the last Ethernet port number and the first POS number (POS Port 0). Port numbers for the interfaces are listed in Table 22-1:

Table 22-1 Port Numbers for the Interfaces of ML-Series Cards

ML100T-12 FastEthernet Interfaces

ML100T-12 POS Interfaces

ML100X-8 FastEthernet Interfaces

ML100X-8 POS Interfaces

ML1000-2 Gigabit Ethernet Interfaces

ML1000-2 POS Interfaces

FE 0 = Port 0

POS 0 = Port 13

FE 0 = Port 0

POS 0 = Port 9

GE 0 = Port 0

POS 0 = Port 3

FE 1 = Port 1

POS 1 = Port 14

FE 1 = Port 1

POS 1 = Port 10

GE 1 = Port 1

POS 1 = Port 4

FE 2 = Port 2

FE 2 = Port 2

FE 3 = Port 3

FE 3 = Port 3

FE 4 = Port 4

FE 4 = Port 4

FE 5 = Port 5

FE 5 = Port 5

FE 6 = Port 6

FE 6 = Port 6

FE 7 = Port 7

FE 7 = Port 7

FE 8 = Port 8

FE 9 = Port 9

FE 10 = Port 10

FE 11 = Port 11

The slot and port are combined to form the ifIndex using the following formula:

ifIndex = (slot * 10000h) + (port)

10000h is the hexadecimal equivalent number of 65536. The resulting ifIndex is a meaningful two-part number in hexadecimal, but seems confusing and arbitrary in decimal. For example, ifIndex E0002h is Slot 14, Port 2. This same number in decimal notation is 917506. The rmon alarm command requires the ifindex number in decimal form.

As an additional reference for calculating the correct ifindex value to use with the rmon alarm command, Table 22-1 lists the base ifindex number for Slots 1 to 17. The desired port number can be added to the slot base number to quickly determine the correct ifIndex number.

Table 22-2 Port Numbers for the Interfaces of ML-Series Cards

Slot Number for the ML-Series Card

Base ifIndex Number in Hexidecimal Format

Base ifIndex Number in Decimal Format

1

10000h

65536

2

20000h

131072

3

30000h

196608

4

40000h

262144

5

50000h

327680

6

60000h

393216

12

C0000h

786432

13

D0000h

851968

14

E0000h

917504

15

F0000h

983040

16

100000h

1048576

17

110000h

1114112

Manually Checking CRC Errors on the ML-Series Card

Users can also check the current count of ML-Series card CRC errors on an interface by using the show interface command. The example shows six total input errors, which are all CRC errors, in the last line of the output.

ML_Series(config)# show interface pos 0

POS0 is up, line protocol is up

Hardware is Packet/Ethernet over Sonet, address is 0005.9a39.713e (bia 0005.9a39.713e)

MTU 1500 bytes, BW 48384 Kbit, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 182/255

Encapsulation: Cisco-EoS-LEX, crc 32, loopback not set

Keepalive set (10 sec)

Scramble enabled

ARP type: ARPA, ARP Timeout 04:00:00

Last input never, output never, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 34621000 bits/sec, 60083 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

311190527 packets input, 931220183 bytes

Received 0 broadcasts (0 IP multicast)

6 runts, 0 giants, 0 throttles

0 parity

6 input errors, 6 CRC, 0 frame, 0 overrun, 0 ignored

Displaying RMON Status

Note RMON status commands do not work for POS interfaces.

To display the RMON status, use one or more of the privileged EXEC commands in Table 22-3.