Configuring Ethernet Link Redundancy
You can use 802.3ad Link Aggregation (LAG) to configure Ethernet link redundancy for Fast Ethernet and Gigabit Ethernet interfaces. Ethernet link redundancy enables you to protect against physical link failure and account for network topology changes that redirect network traffic to redundant ports.
The following configurations are available:
- LAG to LAG—Provides redundancy capabilities for two or more ports that are assigned to a LAG. One member link is configured as the backup interface for all other ports in the LAG bundle (1:N). Traffic is not forwarded over the backup member interface; it is disabled until it takes over for an active member interface.
- LAG to non-LAG—Provides redundancy capabilities when redundant ports are connected to a bridged network that has Rapid Spanning Tree Protocol (RSTP) controlling the topology. This configuration supports only two links in the LAG.
For information about the modules that support link aggregation, see ERX Module Guide, Appendix A, Module Protocol Support and E120 and E320 Module Guide, Appendix A, IOA Protocol Support.
Ethernet Link Redundancy Configuration Models
The link connections determine the configuration model for link redundancy. The following connection types are available:
- Single-homed—Connections are between the local Ethernet interface and a single remote device. When the peer is also configured with LAG, LACP can be used to control link access.
- Dual-homed—Connections are between two separate, uncoordinated remote devices. The remote interfaces can be on the same module or on separate hardware. If LAG is not configured on the peers, LACP cannot be used to select ports; other protocols such as RSTP can be used.
The type of hardware used for connections further characterizes the single-homed and dual-homed configuration models. The following hardware types are available:
- Homogeneous—Remote interface is on another Fast Ethernet or Gigabit Ethernet port in a back-to-back router configuration of identical hardware and JUNOSe software versions. Both interfaces support the same redundant cabling and algorithm. The interfaces can be cabled on the same ports (port 0–port 0, port 1–port 1) or cross-cabled (port 0–port 1, port 1–port 0).
- Heterogeneous—Remote interface is on a different type of hardware that might or might not support redundant cabling, or on the same type of equipment with different software versions. For example, a heterogeneous configuration can include an ES2-S1 GE-4 IOA and an ES2-S1 GE-8 IOA on the E320 router, or an E-series router operating JUNOSe software connected to another vendor's router and software.
NOTE: You cannot configure link redundancy across different types of line modules in a router. You also cannot configure link redundancy across two GE-4 IOAs on the E120 router or the E320 router.
Figure 21 illustrates the configuration models for Ethernet link redundancy.
Ethernet Link Redundancy Configuration Diagrams
The diagrams in this section illustrate examples of Ethernet link redundancy configurations. The diagrams display adjacent ports bundled in a LAG.
GE-2 Line Module Configurations
These diagrams compare physical port redundancy and link redundancy on a GE-2 line module.
Figure 22 displays a GE-2 line module with physical port redundancy on both ports.
Figure 23 displays a single-homed configuration with port 0 backing up port 1 on a GE-2 line module.
FE-8 Line Module Configurations
Figure 24 displays an FE-8 line module with a link failure in a 1:N single-homed configuration.
Figure 25 displays an FE-8 line module with four redundant Ethernet links in a 1:1 configuration.
E120 and E320 Router Configurations
Figure 26 and Figure 27 display link redundancy configurations on the E120 and E320 routers.
Figure 26 displays a single-homed 1:4 configuration on an E120 router.
Figure 27 displays an E320 router with 1:N configuration across IOAs.
Dual-Homed Configurations with LAG Disabled
Figure 28 displays how you can configure Ethernet link redundancy with LACP disabled locally using a dual-homed configuration. LACP is disabled because there is no LAG at the peer.
Ethernet Link Redundancy Behavior
When you create a LAG bundle, you can configure LACP with the Disabled, Passive, or Active states. For more information about these states, see LACP.
The following sections describe link redundancy behavior when the:
- Configuration and status of LACP changes during link failure and acquisition.
- Configuration of the endpoints of the member links is different.
- Configuration is LAG to non-LAG in an RSTP network.
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.
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 process when you issue the auto-revert on and auto-revert off keywords:
auto-revert on
- 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.
auto-revert off
- 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 23 lists the acceptable configurations that enable redundant behavior for LACP modes at local and remote endpoints.
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 29 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.
Configuring Ethernet Link Redundancy
To configure Ethernet link redundancy:
- Specify the Fast Ethernet or Gigabit Ethernet interface on which to configure a redundant link.
- For LAG to non-LAG configurations only, specify that LACP is disabled on the port.
- Configure a backup interface and disable LACP on it.
- Configure a LAG interface and assign a member link to the backup interface.
- Do one of the following:
host1(config)#interface gigabitEthernet 1/1
host1(config-if)#no lacp
host1(config)#interface gigabitEthernet 1/0
host1(config-if)#no lacp
host1(config)#interface lag myBundle
host1(config-if)#member-interface gigabitEthernet 1/0
- Configure link redundancy on the port you specified in step 1.
host1(config-if)#redundant-port gigabitEthernet 1/1
host1(config-if)#redundant-port gigabitEthernet 1/1 force-failover
redundant-port
- Use to specify a member link in a LAG bundle as redundant.
- Use the failover timeout keyword to configure the amount of time between the current link event leading to failover or reversion and the previous link failover or reversion.
- Use the packet-sampling keyword to configure redundancy on a LAG to non-LAG application where packet sampling is used for failover detection. Use the optional delay keyword to control the minimum time difference to force packets on the active and redundant port to fail over.
- Use the transmitter keyword to enable or disable the transmitter when in redundant mode.
- Use the auto-revert keyword to instruct the redundant link to revert back to redundant mode when the failed link becomes active again.
- Example 1—Specifies that the Gigabit Ethernet interface in slot 4, port 0 is a redundant member interface
host1(config-if)#redundant-port gigabitEthernet 4/0
host1(config-if)#redundant-port gigabitEthernet 1/1 packet-sampling delay 500
redundant-port force-failover
- Use to force the specified member interface to fail over when more than one active member exists.
- Example
host1(config)#redundant-port gigabitEthernet 4/0 force-failover