Technical Documentation
New
Ethernet Link Redundancy Behavior Overview
When you create a LAG bundle, you can configure LACP with the Disabled, Passive, or Active states. For more information about these states, see Unresolved xref.
The following sections describe link redundancy behavior in various scenarios:
Link Failure and Acquisition
Link failure on the local system occurs when the active link is no longer active. Failures can be characterized as physical link failure or virtual link failure.
Each type of link failure has different requirements for detection, failover, and link acquisition. In all cases, you configure the link to fail over when it fails by issuing the redundant-port command . Optionally, you can force the failover automatically by issuing the redundant-port force-failover command
Protecting Against Physical Link Failure
Physical link failures can occur when a cable is cut.
To protect against physical link failure, issue the transmitter keyword with the redundant-port command to enable or disable the local redundant link. When the redundant link needs to be down, the link behavior in failure detection and failover follows a similar port redundancy scheme available with line modules such as the GE-2 line module. Disabling the transmitter also enables the remote end of the redundant link to be in the operational Down state, which might be a requirement for third-party equipment when supporting redundancy over LAG.
Enabling the transmitter provides for a quick LAG failover in the event one of the non-redundant links in the LAG fail. This is particularly true when LACP has been enabled on the LAG, because it can take several seconds for LACP to converge on a link. When the transmitter on the remote end is enabled on the redundant link before it fails over, the local system considers the redundant link to be viable and enables the transmitter if it is disabled. If the remote end is disabled, the local end must enable the transmitter and wait for the remote end to enable.
Protecting Against Virtual Link Failure
A virtual link failure can occur when the active link is no longer used by the network because of topology changes caused by physical failure in the network. Topology changes can occur when, for example, a link is blocked because of network protocols such as RSTP blocking the port leading to selection of the redundant port connected to the receiver.
To protect against virtual link failure in conjunction with network protocols, use the packet-sampling keyword with the redundant-port command to detect link the viability. For example, when there is a network protocol decision that changes the topology and blocks a link to compensate for failures in the network, the system monitors the traffic to detect the change in network topology and fails over to the redundant port if necessary. It also determines whether the failover is successful. For more information, see Member Link with Non-LAG Partner.
Reverting After a Failover
When you specify the auto-revert keyword with the redundant-port command, the redundant link reverts back to redundant mode when the failed link becomes active again.
The system uses the following processes when the auto-revert feature is enabled (by specifying the auto-revert keyword) or disabled.
When auto-revert is enabled:
- An active link fails and a redundant link becomes active.
- The original active link becomes active.
- The original redundant link fails over to the original active link.
- The redundant link can fail over to any other active link again.
When auto-revert is disabled:
- An active link fails and a redundant link becomes active.
- The original active link becomes active.
- The original redundant link remains the active link.
- You can force the link to fail over by issuing the redundant-port force-failover command.
LACP Configuration and Member Link Behavior
By default, when a redundant member link is configured, the system disables LACP and the transmitter on that link.
When a member link is administratively down, the link state is operationally down at the local and remote ends, which means it does not transmit or receive PDUs.
The active link does not fail over when:
- An active link goes down and you set the redundant member link to administratively down.
- An active link is set to administratively down.
LACP configurations affect member link behavior based on the local or remote endpoint. For a remote end to include a member link in link aggregation, the two member links that are connected must have LACP configured.
Table 1 lists the acceptable configurations that enable redundant behavior for LACP modes at local and remote endpoints.
Table 1: Behavior of Member Links Using Local and Remote LACP Modes
| Remote LACP Mode | |||
|---|---|---|---|---|
| Disabled | Passive | Active | |
Local LACP Mode | Disabled | ✓ | ✓ | – |
Passive | ✓ | ✓ | ✓ | |
Active | – | ✓ | ✓ | |
Member Link with Non-LAG Partner
When a member link has a non-LAG partner, there are two separate links in a 1:1 configuration. To successfully configure this, you must disable LACP.
When a failover occurs and LACP is active, the partner might receive a new LAG ID and the LACP PDUs receive a new MAC address; therefore, the member links are not aggregated or the bundle is disabled, terminating the sessions above it.
The partner that is connected to the redundant link must not be forwarding network traffic; that is, it is either blocked through a protocol such as RSTP, or MAC address learning has selected the active port. The redundant link must not transmit over the redundant link to that MAC. The behavior of the redundant link depends on the failure detection method that is controlled by the network protocol that is blocking the port.
Ethernet Link Redundancy and RSTP
In a LAG to non-LAG configuration, you can configure redundancy capabilities when redundant ports are connected to a bridged network that has RSTP controlling the topology.
On external devices, we recommend that you configure RSTP-enabled bridged ports that are connected to the LAG interfaces as edge ports to enable the ports to transition quickly to forwarding state upon reconfiguration, and to avoid the listening and learning states required by the spanning tree protocol. The edge port designation instructs the local bridge that bridge loops do not exist through the interface, enabling it to skip the listening and learning states.
Figure 1: Dual-Homed Heterogeneous Configuration in an RSTP Network
Figure 1 displays a network with RSTP enabled on Gigabit Ethernet switches 1 and 2. The local port receives bridge PDUs (BPDU), Ethernet broadcasts, and flooded unicast packets. If Link 1 is initially active and Link 2 is the backup, initial traffic destined for the LAG can be Ethernet broadcasts, PPPoE PDUs, or flooded Ethernet unicasts. The responses are only sent on the active link; in this case, Link 1.
The Ethernet network topology that is managed by RSTP learns that the MAC for the LAG group is through Link 1. Broadcasts and flooded packets are still sent on Link 2. If Link 1 is no longer viable, but has not suffered a physical failure, then that address ages out of the bridge databases and any packets directed to the LAG are flooded. The LAG detects traffic on Link 2 after the minimum delay time and then fails over.
Acquiring Initial Links
In an RSTP network, the system uses the following process for acquiring new links:
- Based on the configuration, the system selects a link as active and the other as redundant.
- The spanning tree converges on a topology.
- When convergence occurs and the status of the spanning tree ports change to forwarding, network traffic appears on the links.
- The local port detects the traffic and confirms the active member as active and the other as the redundant port. Because the initial traffic is broadcast or flooded, both ports receive the packets. However, because of the timing difference, the selected active port remains active.
Detecting Failures
In an RSTP network, the system uses the following process for detecting when the link has switched over due to topology changes:
- BPDUs are ignored on the redundant port and system time is not retrieved. Because MAC learning forces non-flooded unicast packets to the active link, traffic to the redundant link does not receive non-flooded packets. The most recent system time is always retrieved when a network packet is received.
- When the network cannot reach the active link because of topology changes, traffic appears on the redundant link. The redundant port detects the traffic and captures the latest timestamp. When the difference between the timestamp of the first non-bridged PDU and the time the last packet that was received on the active port is sufficiently large to account for the minimum spanning tree convergence time and latency for flooded and broadcast packets, then the port fails over.
Failing Over
In an RSTP network, the system uses the following process to fail over:
- When the link has failed over, the system monitors the previously active port.
- When a network packet is received on the redundant port, the system retrieves the timestamp. If the difference in timestamps between that one and the most recent on the current active port is more than the configured failover delay time, then the link fails over. If the difference is less than the delay time, the system ignores it but counts the event. If many of these transitions occur in a time period, then the system administratively brings the ports down. If no network traffic is received on either port, then failover does not occur.
