60
Ring recovery
After the ports belonging to the RRPP domain on the transit nodes, the edge nodes, or the assistant-edge
nodes are brought up again, the master node may find the ring is restored after a period of time. A
temporary loop may arise in the data VLAN during this period, resulting in a broadcast storm.
To prevent temporary loops, when non-master nodes find that their ports accessing the ring are brought
up again, they block them immediately and permit only the packets of the control VLAN to pass through.
The blocked ports are activated only when the nodes are sure that the ports will not cause a loop.
Broadcast storm suppression mechanism in case of SRPT failure in a multi-homed subring
As shown in
, Ring 1 is the primary ring, and Ring 2 and Ring 3 are subrings. When the two
SRPTs between the edge node and the assistant-edge node are down, the master nodes of Ring 2 and
Ring 3 open their respective secondary ports, and a loop among Device B, Device C, Device E, and
Device F is generated. As a result, broadcast storm occurs.
To prevent generating this loop, the edge node temporarily blocks the edge port. The blocked edge port
is activated only when the edge node is sure that activating it will not cause a loop.
Load balancing
In a ring network, traffic of multiple VLANs may be transmitted at the same time. RRPP can implement
load balancing for the traffic by transmitting traffic of different VLANs along different paths.
By configuring an individual RRPP domain for transmitting the traffic of the specified VLANs (protected
VLANs) in a ring network, traffic of different VLANs can be transmitted according to different topologies
in the ring network. In this way, load balancing is achieved.
As shown in
, Ring 1 is configured as the primary ring of Domain 1 and Domain 2, which are
configured with different protected VLANs. Device A is the master node of Ring 1 in Domain 1; Device
B is the master node of Ring 1 in Domain 2. With such configurations, traffic of different VLANs can be
transmitted on different links to achieve load balancing in the single-ring network.
RRPP ring group
In an edge node RRPP ring group, only an activated subring with the lowest domain ID and ring ID can
send Edge-Hello packets. In an assistant-edge node RRPP ring group, any activated subring that has
received Edge-Hello packets will forward these packets to the other activated subrings. With an edge
node RRPP ring group and an assistant-edge node RRPP ring group configured, only one subring sends
Edge-Hello packets on the edge node, and only one subring receives Edge-Hello packets on the
assistant-edge node, reducing CPU workload.
As shown in
, Device B is the edge node of Ring 2 and Ring 3, and Device C is the
assistant-edge node of Ring 2 and Ring 3. Device B and Device C need to send or receive Edge-Hello
packets frequently. If more subrings are configured or load balancing is configured for more multiple
domains, Device B and Device C will send or receive a mass of Edge-Hello packets.
To reduce Edge-Hello traffic, you can assign Ring 2 and Ring 3 to an RRPP ring group configured on the
edge node Device B, and assign Ring 2 and Ring 3 to an RRPP ring group configured on Device C. After
such configurations, if all rings are activated, only Ring 2 on Device B sends Edge-Hello packets.
Fast detection mechanism
Ideally, an RRPP ring can fast converge because the transit nodes on it can detect link failures fast and
send out notifications immediately. In practice, some devices on an RRPP ring may not support RRPP. RRPP
can detect link failures between these devices only through the timeout mechanism. This results in
long-time traffic interruption and failure to implement millisecond-level convergence.
To address this problem, a fast detection mechanism was introduced. The mechanism works as follows:
