Chapter 20
| ERPS Commands
– 499 –
Default Setting
Disabled
Command Mode
ERPS Configuration
Command Usage
◆
The RPL owner node detects a failed link when it receives R-APS (SF - signal
fault) messages from nodes adjacent to the failed link. The owner then enters
protection state by unblocking the RPL. However, using this standard recovery
procedure may cause a non-EPRS device to become isolated when the ERPS
device adjacent to it detects a continuity check message (CCM) loss event and
blocks the link between the non-ERPS device and ERPS device.
CCMs are propagated by the Connectivity Fault Management (CFM) protocol as
described under “CFM Commands” on page 691. If the standard recovery
procedure were used as shown in the following figure, and node E detected
CCM loss, it would send an R-APS (SF) message to the RPL owner and block the
link to node D, isolating that non-ERPS device.
Figure 2: Non-ERPS Device Protection
When non-ERPS device protection is enabled on the ring, the ring ports on the
RPL owner node and non-owner nodes will not be blocked when signal loss is
detected by CCM loss events.
◆
When non-ERPS device protection is enabled on an RPL owner node, it will
send non-standard health-check packets to poll the ring health when it enters
the protection state. It does not use the normal procedure of waiting to receive
an R-APS (NR - no request) message from nodes adjacent to the recovered link.
Instead, it waits to see if the non-standard health-check packets loop back. If
they do, indicating that the fault has been resolved, the RPL will be blocked.
After blocking the RPL, the owner node will still transmit an R-APS (NR, RB - ring
blocked) message. ERPS-compliant nodes receiving this message flush their
forwarding database and unblock previously blocked ports. The ring is now
returned to Idle state.
Example
Console(config-erps)#non-erps-dev-protect
Console(config-erps)#
non-ERPS
A
non-ERPS
RPL
Owner
RPL
XX
blocked blocked
fault
BCD EF
To Next Page
Loading...
Need help?
General