Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Configuring Multichassis Link Aggregation on EX Series Switches

Multichassis link aggregation groups (MC-LAGs) enable a client device to form a logical LAG interface between two MC-LAG peers (for example, EX9200 switches). An MC-LAG provides redundancy and load balancing between the two MC-LAG peers, multihoming support, and a loop-free Layer 2 network without running Spanning Tree Protocol (STP).

On one end of an MC-LAG, there is an MC-LAG client device, such as a server, that has one or more physical links in a link aggregation group (LAG). This client device does not need to have an MC-LAG configured. On the other side of MC-LAG, there are two MC-LAG peers. Each of the MC-LAG peers has one or more physical links connected to a single client device.

The MC-LAG peers use Inter-Chassis Control Protocol (ICCP) to exchange control information and coordinate with each other to ensure that data traffic is forwarded properly.

Note: An interface with an already configured IP address cannot form part of the aggregated Ethernet interface or multichassis aggregated Ethernet interface group.

For information about MC-LAG functional behaviors, see the “MC-LAG Configuration Guidelines and Functional Behavior” section in the topic Understanding Multichassis Link Aggregation. .

1. Specify the same multichassis aggregated Ethernet identification number for the MC-LAG that the aggregated Ethernet interface belongs to on each switch.
   [edit interfaces]
user@switch# set aex aggregated-ether-options mc-ae mc-ae-id number

   For example:

   [edit interfaces]
user@switch# set ae1 aggregated-ether-options mc-ae mc-ae-id 3
2. Specify a unique chassis ID for the MC-LAG that the aggregated Ethernet interface belongs to on each switch.
   [edit interfaces]
user@switch# set aex aggregated-ether-options mc-ae chassis-id number

   For example:

   [edit interfaces]
user@switch# set ae1 aggregated-ether-options mc-ae chassis-id 0
3. Specify the mode of the MC-LAG the aggregated Ethernet interface belongs to.
   [edit interfaces]
user@switch# set aex aggregated-ether-options mc-ae mode mode

   For example:

   [edit interfaces]
user@switch# set ae1 aggregated-ether-options mc-ae mode active-active
4. Specify whether the aggregated Ethernet interface participating in the MC-LAG is primary or secondary.

   Primary is active, and secondary is standby.

   Note: You must configure status control on both switches that host the MC-LAG. If one switch is in active mode, the other must be in standby mode.

   [edit interfaces]
user@switch# set aex aggregated-ether-options mc-ae status-control (active | standby)

   For example:

   [edit interfaces]
user@switch# set ae1 aggregated-ether-options mc-ae status-control active

   Note: 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 LACP system ID on ICCP failure. Use this configuration only if you can ensure that ICCP will not go down unless the switch is down. 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 BFD timeout. This configuration prevents data traffic loss by ensuring that when the switch with the mc-ae status-control active configuration goes down, the 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. On EX9200 switches, the prefer-status-control-active statement was added in Junos OS Release 13.2R1.

5. Specify the same LACP system ID on each switch.
   [edit interfaces]
user@switch# set aex aggregated-ether-options lacp system-id mac-address

   For example:

   [edit interfaces]
user@switch# set ae1 aggregated-ether-options lacp system-id 00:01:02:03:04:05
6. Specify the same LACP administration key on each switch.
   [edit interfaces]
user@switch# set aex aggregated-ether-options lacp admin-key number

   For example:

   [edit interfaces]
user@switch# set ae1 aggregated-ether-options lacp admin-key 3
7. Configure ICCP by performing the following steps on each switch that hosts the MC-LAG:
   1. Configure the local IP address to be used by the switches that host the MC-LAG.
      [edit protocols]
user@switch# set iccp local-ip-addr local-ip-address

      For example:

      [edit protocols]
user@switch# set iccp local-ip-addr 3.3.3.1
   2. (Optional) Configure the IP address of the switch and the time during which an ICCP connection must be established between the switches that host the MC-LAG.

      Configuring the session establishment hold time helps to establish a faster ICCP connection . The recommended value is 50 seconds.

      [edit protocols]
user@switch# set iccp peer peer-ip-address session-establishment-hold-time seconds

      For example:

      [edit protocols]
user@switch# set iccp peer 3.3.3.2 session-establishment-hold-time 50
   3. (Optional) Configure the backup-liveness-detection statement on the management interface (fxp0) only.

      We recommend that you configure the backup liveness detection feature to implement faster failover of data traffic during an MC-LAG peer reboot.

      Note: On EX9200 switches, the backup-liveness-detection statement was added in Junos OS Release 13.2R1.

      [edit protocols]
user@switch# set iccp peer peer-ip-address backup-liveness-detection backup-peer-ip ip-address

      For example:

      [edit protocols]
user@switch# set iccp peer 3.3.3.2 backup-liveness-detection backup-peer-ip 10.207.64.232
   4. Configure the minimum interval at which the switch must receive a reply from the other switch with which it has established a Bidirectional Forwarding Detection (BFD) session.

      Note: Configuring the minimum receive interval is required to enable BFD. We recommend a minimum receive interval value of 60 seconds.

      [edit protocols]
user@switch# set iccp peer peer-ip-address liveness-detection minimum-receive-interval seconds

      For example:

      [edit protocols]
user@switch# set iccppeer 3.3.3.2 liveness-detection minimum-receive-interval 60
   5. Configure the minimum transmit interval during which a switch must receive a reply from a switch with which it has established a BFD session.
      [edit protocols]
user@switch# set iccp peer peer-ip-address liveness-detection transmit-interval minimum-interval seconds

      For example:

      [edit protocols]
user@switch# set iccp peer 3.3.3.2 liveness-detection transmit-interval minimum-interval 60
8. Configure a multichassis protection link between the switches.
   [edit]
user@switch# set multi-chassis multi-chassis-protection peer-ip-address interface interface-name

   For example:

   [edit protocols]
user@switch# set multi-chassis multi-chassis-protection 3.3.3.1 interface ae0