21-8
Ethernet Card Software Feature and Configuration Guide, R7.2
January 2009
Chapter 21 Configuring RMON
Unwrap Synchronization
Before doing a manual clear, the user needs to determine the root cause of a CRC-ALARM and correct
it. After that, the user has several alternative methods to manually clear the alarm:
Through the Cisco IOS CLI, enter the clear crc alarm interface interface-type interface-number
command at the EXEC level.
Through the Cisco IOS CLI, do an administrative shutdown on the linked ports and then a no
shutdown to enable the ports.
Through CTC or TL-1, disable and then re-enable the circuit.
Through CTC or TL-1, delete the SONET/SDH circuit and create a replacement circuit with the
same source and destination.
Unwrap Synchronization
The software on the ML-Series card raises the CRC-ALARM alarm on the POS interface that sees the
errored frames. For unidirectional FCS errors, the user only needs to issue the unwrap command on the
POS port at one end of the span, the one which raised the CRC-ALARM alarm. For bidirectional failures,
both ends of the span raise the CRC-ALARM alarm and the user is required to issue the command once
at each end of the span.
Since the POS ports at each end of the link are wrapped, removing the wra p (unwrapping) when the
CRC-ALARM is cleared requires coordination. The software must also make sure that other errors that
might cause wrapping are absent. The following examples illustrate this process for both unidirectional
and bidirectional failures. For simplicity, the examples assume that excessive CRC errors is the only
existing condition that might cause wrapping.

Unidirectional Errors

Figure 21-2 shows an Cisco proprietary RPR wrapped by excessive unidirectional CRC errors on POS
port 0 of node E, which is also reporting the CRC-ALARM. This caused POS port 1 on node E and POS
port 0 on node D to wrap. The figure captions further explain the p rocess.