Configuring ml-series card rmon for crc errors, Accessing crc errors through snmp – Cisco 15327 User Manual

Page 359

Advertising
background image

21-15

Ethernet Card Software Feature and Configuration Guide, R7.2

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

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.

Advertising