21-15
Ethernet Card Software Feature and Configuration Guide, R7.2
January 2009
Chapter 21 Configuring RMON
Configuring ML-Series Card RMON for CRC Errors
Beginning in privileged EXEC mode, follow these steps to clear the ML-Series card CRC-ALARM:
Configuring ML-Series Card RMON for CRC Errors
The ML-Series card supports using an NMS for SNMP performanc e monitoring (PM), including
monitoring cyclic redundancy check (CRC) errors. If the NMS supports periodic polling an d
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 NM S.
If the NMS does not support polling or if the desired polling f requency 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 Control ler (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 n o 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 t ime 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 ifInE rrors (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
Command Purpose
Step 1 ML_Series # clear crc alarm interface interface-type
interface-number
Clears the SONET/SDH CRC-ALARM and allows
the Cisco proprietary RPR to unwrap when
conditions are met.