API 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)
349