Administrator Guide

Ring Status
The ring failure notification and the ring status checks provide two ways to ensure the ring remains up and active in the event of a switch
or port failure.
Ring Checking
At specified intervals, the Master node sends a ring health frame (RHF) through the ring. If the ring is complete, the frame is received on
its secondary port and the Master node resets its fail-period timer and continues normal operation.
If the Master node does not receive the RHF before the fail-period timer expires (a configurable timer), the Master node moves from the
Normal state to the Ring-Fault state and unblocks its Secondary port. The Master node also clears its forwarding table and sends a control
frame to all other nodes, instructing them to also clear their forwarding tables. Immediately after clearing its forwarding table, each node
starts learning the new topology.
Ring Failure
If a Transit node detects a link down on any of its ports on the FRRP ring, it immediately sends a link-down control frame on the Control
VLAN to the Master node.
When the Master node receives this control frame, the Master node moves from the Normal state to the Ring-Fault state and unblocks its
Secondary port. The Master node clears its routing table and sends a control frame to all other ring nodes, instructing them to clear their
routing tables as well. Immediately after clearing its routing table, each node begins learning the new topology.
Ring Restoration
The Master node continues sending ring health frames out its primary port even when operating in the Ring-Fault state.
After the ring is restored, the next status check frame is received on the Master node's Secondary port. This causes the Master node to
transition back to the Normal state. The Master node then logically blocks non-control frames on the Secondary port, clears its own
forwarding table, and sends a control frame to the Transit nodes, instructing them to clear their forwarding tables and re-learn the
topology.
During the time between the Transit node detecting that its link is restored and the Master node detecting that the ring is restored, the
Master node’s Secondary port is still forwarding traffic. This can create a temporary loop in the topology. To prevent this, the Transit node
places all the ring ports transiting the newly restored port into a temporary blocked state. The Transit node remembers which port has
been temporarily blocked and places it into a pre- forwarding state. When the Transit node in the pre-forwarding state receives the
control frame instructing it to clear its routing table, it does so and unblocks the previously blocked ring ports on the newly restored port.
Then the Transit node returns to the Normal state.
Multiple FRRP Rings
Up to 255 rings are allowed per system and multiple rings can be run on one system.
More than the recommended number of rings may cause interface instability. You can configure multiple rings with a single switch
connection; a single ring can have multiple FRRP groups; multiple rings can be connected with a common link.
The platform supports up to 32 rings on a system (including stacked units).
Member VLAN Spanning Two Rings Connected by One Switch
A member VLAN can span two rings interconnected by a common switch, in a figure-eight style topology.
A switch can act as a Master node for one FRRP group and a Transit for another FRRP group, or it can be a Transit node for both rings.
In the following example, FRRP 101 is a ring with its own Control VLAN, and FRRP 202 has its own Control VLAN running on another ring.
A Member VLAN that spans both rings is added as a Member VLAN to both FRRP groups. Switch R3 has two instances of FRRP running
on it: one for each ring. The example topology that follows shows R3 assuming the role of a Transit node for both FRRP 101 and FRRP
202.
Force10 Resilient Ring Protocol (FRRP)
261