This document describes how to configure the Cisco ML-Series Card to wrap the Resilient Packet Ring (RPR) when you face signal degrade.
Cisco recommends that you have knowledge of these topics:
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
The Cisco ML-Series RPR currently performs wrap resiliency, and the wrapping technique is simple. The ML-Series RPR simply redirects packets on a wrapped ring if the packets reach a failure point. Therefore, only the nodes adjacent to the failure need to be aware of the issue and initiate the wrap. Wrapping also offers sub-50-ms resiliency and maintains the same network convergence times, regardless of the network size.
Figure 1 represents an example for wrapping. The traffic from S3 to S4 traverses two nodes in the normal condition (see arrow A in Figure 1). The path is S3 > S4. Link failure between S3 and S4 results in a wrap, and the traffic from S3 to S4 traverses four nodes, S3 > S2 > S1 > S4 (see arrow B in Figure 1).
Figure 1 – The Cisco ML-Series RPR Wrapping
If the pos trigger defects ber_sd_b3 command is not configured, the ML does not wrap the ring upon signal degrade, which only occurs upon a Signal Failure (LOS, LOF) condition.
It is important to note that CTC version 6.2 has a new feature called RPR Keepalive. RPR Keepalive wraps the ring if a signal degrade condition plus other conditions, such as a possible hardware failure, occur. If you can upgrade the nodes to the 6.2 version, it is recommended that you use the RPR Keepalive feature.
For more information, refer to RPR Keep Alive section of Configuring Resilient Packet Ring.
The Cisco ML-Series RPR wraps only when a signal failure alarm occurs due to cut fiber. In case of a span with signal degrade, the RPR drops packets. The show controller pos X command presents an increase in ber_sd_b3, BIP(B3) errors and results in input CRCs and runts. In the show controller pos X command, X can be 0 or 1.
One possible reason for this issue is a faulty line card that connects two nodes, for example, OC-48. The other possibility is high B3 Bit Error Rate (BER). This condition can be caused by a dirty fiber, loose connector, faulty transmitter, or faulty receiver.
If a faulty line card causes this issue, check the light levels and clean the fibers. If the problem persists, replace the line card in order to solve the problem. Line card replacement is usually the last resort. However, while you perform these steps, critical traffic can be affected. In order to avoid packet drops, force the POS interface to shut down automatically under SD condition, wrapping the RPR ring.
If the issue occurs due to excessive Path Bit-Interleaved Parity (PBIP) BER in excess of the Signal Degrade (SD) threshold, configure this line under the POS interface on the ML-Series Card (see arrow A in Figure 2).
pos trigger defects ber_sd_b3
This line reduces the number of wraps.
Figure 2 – POS Trigger Defects ber_sd_b3
You can set the SD threshold when you create a new circuit (see arrow A in Figure 3).
The default values for POS trigger defects do not include ber_sd_b3. After you add this command, the ML-Series RPR wraps when the SD threshold is reached.
Figure 3 – Set the SD Threshold