Non-Erps-Dev-Protect - Edge-Core ES3528MV2 Management Manual

| ERPS Commands
C 35
HAPTER
non-erps-dev-
protect
For example, a node that has one ring port in SF condition and detects
that the condition has been cleared, will continuously transmit R-APS
(NR) messages with its own Node ID as priority information over both
ring ports, informing its neighbors that no request is present at this
node. When another recovered node holding the link blocked receives
this message, it compares the Node ID information with its own. If the
received R-APS (NR) message has a higher priority, this unblocks its
ring ports. Otherwise, the block remains unchanged.
◆ The node identifier may also be used for debugging, such as to
distinguish messages when a node is connected to more than one ring.
E
XAMPLE
Console(config-erps)#node-id 00-12-CF-61-24-2D
Console(config-erps)#
This command sends non-standard health-check packets when an owner
node enters protection state without any link down event having been
detected through SF messages. Use the no form to disable this feature.
S
YNTAX
[no] non-erps-dev-protect
D S
EFAULT ETTING
Disabled
C M
OMMAND ODE
ERPS Configuration
C U
OMMAND SAGE
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
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.
– 1102 –
"CFM Commands" on page 1319. If the