Download This Guide
Supported Platforms
Related Documentation
Multichassis Link Aggregation Guidelines
This topic provides configuration guidelines and information regarding the functional behavior of multichassis link aggregation.
MC-LAG Configuration Guidelines and Functional Behavior
When you configure MC-LAGs, we recommend that you follow certain guidelines to ensure that you obtain optimum benefit from the MC-LAG feature.
Table 1 provides best practice configuration guidelines for MC-LAGs, and Table 2 describes important functional behavior for MC-LAGs.
Table 1: MC-LAG Configuration Guidelines
We recommend that you use separate ports and choose different FPCs for the interchassis link (ICL) and Inter-Chassis Control Protocol (ICCP) interfaces. |
On QFX Series switches and EX9200 switches, we recommend that you configure the backup liveness detection feature to implement faster failover of data traffic during an MC-LAG peer reboot. Configure the backup-liveness-detection statement on the management interface (fxp0) only. The backup liveness detection should be set to greater than or equal to 1 second on a QFX5100 switch. Note: On EX9200 switches, the backup-liveness-detection statement was added in Junos OS Release 13.2R1. Configure the ICCP liveness-detection interval (the BFD timer) to be at least 8 seconds if you have configured ICCP connectivity through an IRB interface. A liveness-detection interval of 8 seconds or more allows graceful Routing Engine switchover (GRES) to work seamlessly. By default, ICCP liveness detection uses multihop BFD, which runs in centralized mode. This recommendation does not apply if you have configured ICCP connectivity through a dedicated physical interface. In this case, you can configure single-hop BFD. Use the peer loopback address to establish ICCP peering. Doing so avoids any direct link failure between MC-LAG peers. As long as the logical connection between the peers remains up, ICCP stays up. Configure a session establishment hold time for ICCP. Doing so results in faster ICCP connection establishment. The recommended value is 50 seconds. Configure a hold-down timer on the ICL member links that is greater than the configured BFD timer for the ICCP interface. This prevents the ICL from being advertised as being down before the ICCP link is down. If the ICL goes down before the ICCP link, this causes a flap of the MC-LAG interface on the status-control standby node, which leads to a delay in convergence. |
The following two methods can be used to enable Layer 3 functionality across an MC-LAG. We recommend that you use the Virtual Router Redundancy Protocol (VRRP) over integrated routing and bridging (IRB) interfaces method. Use media access control (MAC) address synchronization only when you cannot configure VRRP over IRB. Note: On QFX Series switches, you cannot configure both VRRP over IRB and MAC synchronization, because processing MAC addresses might not work.
|
You must configure the ICL interface as a router-facing interface (by configuring the multicast-router-interface statement) for multicast forwarding to work in an MC-LAG environment. |
You must configure the multichassis-lag-replicate-state statement for Internet Group Management Protocol (IGMP) snooping to work properly in an MC-LAG environment. |
You must enable Protocol Independent Multicast (PIM) on the IRB interface to avoid multicast duplication. |
If you are using Layer 3 multicast, configure the IP address on the active MC-LAG peer with a high IP address or a high designated router priority. |
Note: Use this configuration guideline only if you can ensure that the ICCP will not go down unless the router or switch is down. You can configure the prefer-status-control-active statement with the mc-ae status-control standby configuration to prevent the LACP MC-LAG system ID from reverting to the default Link Aggregation Control Protocol (LACP) system ID on ICCP failure. You must also configure the hold-time down value (at the [edit interfaces interface-name] hierarchy level) for the ICL with the mc-ae status-control standby configuration to be higher than the ICCP Bidirectional Forwarding Detection (BFD) timeout. This configuration prevents data traffic loss by ensuring that when the router or switch with the mc-ae status-control active configuration goes down, the router or switch with the mc-ae status-control standby configuration does not go into standby mode. To make the prefer-status-control-active configuration work with the mc-ae status-control standby configuration when an ICL logical interface is configured on an aggregated Ethernet interface, you must either configure the lacp periodic interval statement at the [edit interfaces interface-name aggregated-ether-options] hierarchy level as slow or configure the detection-time threshold statement at the [edit protocols iccp peer liveness-detection] hierarchy level as less than 3 seconds. Note: On EX9200 switches, the prefer-status-control-active statement was added in Junos OS Release 13.2R1. |
We recommend that you configure the ICCP liveness-detection interval to be at least 8 seconds, to allow graceful Routing Engine switchover to work seamlessly. By default, ICCP liveness detection uses multihop BFD, which runs in centralized mode. If you have configured ICCP connectivity through a dedicated physical interface rather than through an IRB interface, then you can configure single-hop BFD, and the restriction on the the liveness-detection interval does not apply. |
We recommend that you configure only one redundancy group between MC-LAG nodes. The redundancy group represents the domain of high availability between the MC-LAG nodes. One redundancy group is sufficient between a pair of MC-LAG nodes. |
In a MC-LAG active/active environment, we recommend that you use the bootp relay agent by configuring the DHCP relay agent with the forwarding options helpers bootp command to avoid stale session information issue that may arise for clients when the routers is using the extended DHCP relay agent (jdhcp) process. If your environment only supports IPv6 or you must use the extended DHCP relay agent (jdhcp) process for other reasons, then as a workaround, you can configure forward-only support by using the forwarding-options dhcp-relay forward-only command for IPv4 and the forwarding-options dhcpv6 forward-only command for IPv6. You must also verify that your DHCP server in the network supports option 82. |
Table 2: MC-LAG Functional Behavior
STP is not supported on the ICL or MC-LAG interfaces. |
Load balancing of network traffic between MC-LAG peers is 100 percent local bias. |
Load balancing of network traffic between multiple LAG members in a local MC-LAG node is achieved through a standard LAG hashing algorithm. |
MAC learning is disabled on the ICL. Consequently, source MAC addresses cannot be learned locally on the ICL. However, MAC addresses from a remote MC-LAG node can be installed on the ICL interface. For example, the MAC address for a single-homed client on a remote MC-LAG node can be installed on the ICL interface of the local MC-LAG node. |
Dynamic Address Resolution Protocol (ARP) resolution over the ICL interface is not supported. Consequently, incoming address resolution protocol replies on the ICL are discarded. However, ARP entries can be populated on the ICL interface through ICCP exchanges from a remote MC-LAG peer. |
For EX9200 switches, ARP entries that were learned remotely are purged and then learned again during GRES. |
Usually, a VRRP backup node does not forward incoming packets. However, when VRRP over IRB is configured in an MC-LAG active-active environment, both the VRRP master and the VRRP backup forward Layer 3 traffic arriving on the multichassis aggregated Ethernet interface. |
If you are using the MAC address synchronization method (by configuring either the set vlans vlan-name mcae-mac-synchronize or set bridge-domains name mcae-mac-synchronize command) to enable Layer 3 functionality, running routing protocols over the IRB interface is not supported, and gratuitous ARP requests are not sent when the MAC address on the IRB interface changes. |
Access port security features (for example, DHCP snooping, dynamic ARP inspection (DAI), and IP source guard) are not supported on the ICL or MC-LAG interfaces. |
Miswiring Detection Guidelines
You can use STP to detect miswirings. An example of miswiring is when a port of a network element is accidentally connected to another port of the same network element. Using STP to detect loops on MC-LAG interfaces, however, is not supported.
To detect miswirings, we recommend that you do the following:
- Configure STP globally so that STP can detect local miswiring within and across MC-LAG peers.
- Disable STP on ICL links, however, because STP might block ICL interfaces and disable protection.
- Configure MC-LAG interfaces as edge ports.
- Enable bridge protocol data unit (BPDU) block on edge.
- •Do not enable bridge protocol data unit (BPDU) block on interfaces connected to aggregation switches.
For more information about BPDU block, see Understanding BPDU Protection for STP, RSTP, and MSTP.
MC-LAG Upgrade Guidelines
Upgrade the MC-LAG peers according to the following guidelines.
 | Note: Upgrade both MC-LAG nodes to the same software version in order to achieve no loss during stable and failover conditions. The protocol states, data forwarding, and redundancy are guaranteed only after both nodes are upgraded to the same software version successfully. |
| Note: After a reboot, the multichassis aggregated Ethernet interfaces come up immediately and might start receiving packets from the server. If routing protocols are enabled, and the routing adjacencies have not been formed, packets might be dropped. To prevent this scenario, issue the set interfaces interface-name aggregated-ether-options mc-ae init-delay-time time command to set a time by which the routing adjacencies are formed. The init-delay-time should be set to greater than or equal to 240 seconds on a QFX5100 switch. |
- Make sure that both of the MC-LAG peers (node1 and node2)
are in the active-active state using the following command on any
one of the MC-LAG peers:
user@switch> show interfaces mc-ae id 1Member Link : ae0 Current State Machine's State: mcae active state Local Status : active<<<<<<< Local State : up Peer Status : active<<<<<<< Peer State : up Logical Interface : ae0.0 Topology Type : bridge Local State : up Peer State : up Peer Ip/MCP/State : 20.1.1.2 ae2.0 up - Upgrade node1 of the MC-LAG.
When node1 is upgraded, it is rebooted, and all traffic is sent across the available LAG interfaces of node2, which is still up. The amount of traffic lost depends on how quickly the neighbor devices detect the link loss and rehash the flows of the LAG.
- Verify that node1 is running the software you just installed by issuing the show version command.
- Make sure that both nodes of the MC-LAG (node1 and node2) are in the active-active state after the reboot of node1.
- Upgrade node2 of the MC-LAG.
Repeat Step 1 through Step 3 to upgrade node2.
