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
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.
Technical Tips Conventions for more information on document
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 – 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
For more information, refer to RPR Keep Alive section of
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
Figure 3 – Set the SD Threshold