Getting Started with MC-LAG

Configuring Multichassis Link Aggregation on MX Series Routers

Multichassis link aggregation (MC-LAG) enables an MX Series 5G Universal Routing Platform to form a logical LAG interface with two or more other devices. MC-LAG provides additional benefits over traditional LAG in terms of node level redundancy, multihoming support, and a loop-free Layer 2 network without the need to run Spanning Tree Protocol (STP). MC-LAG can be configured for virtual private LAN service (VPLS) routing instances, circuit cross-connect (CCC) applications, and Layer 2 circuit encapsulation types.

The MC-LAG devices use Inter-Chassis Control Protocol (ICCP) to exchange the control information between two MC-LAG network devices.

On one end of the MC-LAG is an MC-LAG client device that has one or more physical links in a link aggregation group (LAG). This client device does not need to be aware of the MC-LAG configuration. On the other side of the MC-LAG are two MC-LAG network devices. Each of these network devices has one or more physical links connected to a single client device. The network devices coordinate with each other to ensure that data traffic is forwarded properly.

MC-LAG includes the following functionality:

Only single-active MC-LAG mode with multi-homed VPLS instance is supported.
MC-LAG operates only between two devices.
Layer 2 circuit functions are supported with ether-ccc and vlan-ccc encapsulations.
VPLS functions are supported with ether-vpls and vlan-vpls encapsulations.

Note:

Ethernet connectivity fault management (CFM) specified in the IEEE 802.1ag standard for Operation, Administration, and Management (OAM) is not supported on MC-LAG interfaces.

To enable MC-LAG, include the mc-ae statement at the [edit interfaces aeX aggregated-ether-options] hierarchy level along with one of the following statements at the [edit interfaces aeX] hierarchy level: encapsulation-ethernet-bridge, encapsulation ethernet-ccc, encapsulation ethernet-vpls, or encapsulation-flexible-ethernet-services. You also need to configure the lacp, admin-key, and system-id statements at the [edit interfaces aeX aggregated-ether-options] hierarchy level:

Note:

When you configure the prefer-status-control-active statement, you must also configure the status-control active statement. If you configure the status-control standby statement with the prefer-status-control-active statement, the system issues a warning.

To delete an MC-LAG interface from the configuration, issue the delete interfaces aeX aggregated-ether-options mc-ae command at the [edit] hierarchy level in configuration mode:

Perform the following steps on each switch that is hosting an MC-LAG:

Specify the same multichassis aggregated Ethernet identification number for the MC-LAG that the aggregated Ethernet interface belongs to on each switch.

For example:

Specify a unique chassis ID for the MC-LAG that the aggregated Ethernet interface belongs to on each switch.

For example:

Specify the mode of the MC-LAG that the aggregated Ethernet interface belongs to.
Note:
Only active/active mode is supported for Reverse Layer 2 Gateway Protocol (R-L2GP) at this time.
For example:
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 hosting the MC-LAG. If one switch is in active mode, the other must be in standby mode.
For example:
Configure the MC-LAG interface to improve Layer 2 and Layer 3 convergence time when a multichassis aggregated Ethernet link goes down or comes up in a bridge domain.

Specify the same LACP system ID on each switch.

For example:

Specify the same LACP administration key on each switch.

For example:

Configure ICCP by doing the following on each switch hosting the MC-LAG:
1. Configure the local IP address to be used by all switches hosting the MC-LAG.
  For example:
2. (Optional) Configure the IP address of the router and the time during which an ICCP connection must succeed between the routers hosting the MC-LAG.
  For example:
3. (Optional) Configure the IP address to be used for backup liveness detection:
  Note:
  By default, backup liveness detection is not enabled. Configure backup liveness detection if you require faster failover of data traffic loss during an MC-LAG peer reboot. Backup liveness detection helps achieve subsecond traffic loss during an MC-LAG peer reboot.
  For example:
4. Configure the minimum interval at which the router must receive a reply from the other router with which it has established a Bidirectional Forwarding Detection (BFD) session.
  Note:
  Configuring the minimum receive interval is required to enable BFD.
  For example:
5. Configure the minimum transmit interval during which a router must receive a reply from a router with which it has established a BFD session.
  For example:
6. Specify the switch service ID.
  The switch service ID is used to synchronize applications, IGMP, ARP, and MAC learning across MC-LAG members.
  For example:

Configure a multichassis protection link between the routers.

For example:

Enable RSTP globally on all interfaces.

Disable RSTP on the interchassis control link protection link (ICL-PL) interfaces on both routers.

For example:

Configure the MC-LAG interfaces as edge ports on both routers.

For example:

Enable BPDU block on all interfaces except for the ICL-PL interfaces on both routers.

For example:

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.

Perform the following steps on each switch that hosts an MC-LAG:

Specify the same multichassis aggregated Ethernet identification number for the MC-LAG that the aggregated Ethernet interface belongs to on each switch.

For example:

Specify a unique chassis ID for the MC-LAG that the aggregated Ethernet interface belongs to on each switch.

For example:

Specify the mode of the MC-LAG the aggregated Ethernet interface belongs to.

For example:

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.
For example:
Note:
If you configure both nodes as prefer-status-control-active, you must also configure ICCP peering using the peer’s loopback address to make sure that the ICCP session does not go down because of physical link failures. Additionally, you must configure backup liveness detection on both of the MC-LAG nodes.

Note:
On EX9200 switches, the prefer-status-control-active statement was added in Junos OS Release 13.2R1.
Specify the init delay time.
The init delay time specifies the number of seconds by which to delay bringing up the MC-LAG interface back to the up state when the MC-LAG peer is rebooted. By delaying the bring-up of the interface until after the protocol convergence, you can prevent packet loss during the recovery of failed links and devices.
For example:

Specify the same LACP system ID on each switch.

For example:

Specify the same LACP administration key on each switch.

For example:

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.
  For example:
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.
  For example:
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.
  
  Note:
  By default, backup liveness detection is not enabled. Configure backup liveness detection if you require minimal traffic loss during a reboot. Backup liveness detection helps achieve sub-second traffic loss during an MC-LAG reboot.
  For example:
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 1000 milliseconds.
  For example:
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.
  For example:
Specify the switch service ID.
The switch service ID is used to synchronize applications, IGMP, ARP, and MAC learning across MC-LAG members.
For example:

Configure a multichassis protection link between the switches.

For example:

Configuring ICCP for MC-LAG

For multichassis link aggregation (MC-LAG), you must configure Inter-Control Center Communications Protocol (ICCP) to exchange information between two MC-LAG peers.

To enable ICCP, include the iccp statement at the [edit protocols] hierarchy level:

The local-ip-address statement sets the source address. This could be a specified address or interface address. The session-establishment-hold-time statement determines whether a chassis takes over as the primary at the ICCP session.

The authentication-key statement is provided by TCP Message Digest 5 (md5) option for an ICCP TCP session. The redundancy-group-id-list statement specifies the redundancy groups between ICCP peers and the liveness-detection hierarchy configures Bidirectional Forwarding Detection (BFD) protocol options.

Note:

ICCP is based on TCP and it uses IP routes to reach the MC-LAG peer. To ensure that the ICCP session is as resilient as possible, we recommend that you configure alternative routes between the ICCP end-point IP addresses. Alternatively, configure a LAG interface that has two or more interfaces between the MC-LAG pairs to prevent session failure when there are no alternative routes.

For Inter-Control Center Communications Protocol (ICCP) in a multichassis link aggregation group (MC-LAG) configured in an active-active bridge domain, you must ensure that you configure the same peer IP address hosting the MC-LAG by including the peer ip-address statement at the [edit protocols iccp] hierarchy level and the multi-chassis-protection peer ip-address statement at the [edit interfaces interface-name] hierarchy level. Multichassis protection reduces the configuration at the logical interface level for MX Series routers with multichassis aggregated Ethernet (MC-AE) interfaces. If the ICCP is UP and the interchassis data link (ICL) comes UP, the router configured as standby will bring up the MC-AE interfaces shared with the peer active-active node specified by the peer statement.

For example, the following statements illustrate how the same peer IP address can be configured for both the ICCP peer and multichassis protection link:

Although you can commit an MC-LAG configuration with various parameters defined for it, you can configure multichassis protection between two peers without configuring the ICCP peer address. You can also configure multiple ICCP peers and commit such a configuration.

ON THIS PAGE

Getting Started with MC-LAG

Configuring Multichassis Link Aggregation on MX Series Routers

Configuring Multichassis Link Aggregation on EX Series Switches

See Also

Configuring ICCP for MC-LAG