Navigation Back up to About Overview

Configuring Active-Active Bridging and VRRP over IRB in Multichassis Link Aggregation on MX Series Routers

The following sections describe the configuration of active-active bridging and VRRP over IRB in multichassis link aggregation (MC-LAG) on MX Series routers:

Configuring MC-LAG

An MC-LAG is composed of logical link aggregation groups (LAGs) and is configured under the [edit interfaces aeX] hierarchy, as follows:

interfaces {ae0 {encapsulation ethernet-bridge;multi-chassis-protection {peer {interface ge-0/0/0;}}aggregated-ether-options {mc-ae {mode active-active; # see note below}}}}

Note: The mode active-active statement is valid only if encapsulation is an ethernet-bridge or extended-vlan-bridge.

Use the mode statement to specify if an MC-LAG is active-standby or active-active. If the ICCP connection is UP and ICL comes UP, the router configured as standby brings up the multichassis aggregated Ethernet interfaces shared with the peer.

Using multi-chassis-protection at the physical interface level is a way to reduce the configuration at the logical interface level.

If there are n+1 logical interfaces under ae0, from ae0.0 through ae0.n, there are n+1 logical interfaces under ge-0/0/0 as well, from ge-0/0/0.0 through ge-0/0/0.n, each ge-0/0/0 logical interface is a protection link for the ae0 logical interface.

Note: A bridge domain cannot have multichassis aggregated Ethernet logical interfaces that belong to different redundancy groups.

Configuring the Interchassis Link-Protection Link

The interchassis link-protection link (ICL-PL) provides redundancy when a link failure (for example, an MC-LAG trunk failure) occurs on one of the active links. The ICL-PL is an aggregated Ethernet interface. You can configure only one ICL-PL between the two peers, although you can configure multiple MC-LAGs between them.

The ICL-PL assumes interface ge-0/0/0.0 is used to protect interface ae0.0 of MC-LAG-1:

interfaces {ae0 {....unit 0 {multi-chassis-protection {peer {interface ge-0/0/0.0;}....}...}}}

The protection interface can be an Ethernet type interface such as ge, or xe, or an aggregated Ethernet (ae) interface.

Configuring Multiple Chassis

A top-level hierarchy is used to specify a multichassis-related configuration, as follows:

multi-chassis {multi-chassis-protection {peer {interface ge-0/0/0;}}}

This example specifies interface ge-0/0/0 as the multichassis protection interface for all the multichassis aggregated Ethernet interfaces which are also part of the peer. This can be overridden by specifying protection at the physical interface level and the logical interface level.

Configuring the Service ID

You must configure the same unique network-wide configuration for a service in the set of PE routers providing the service. You can configure the service IDs under the level of the hierarchies shown in the following examples:

Global Configuration (Default Logical System)

switch-options {service-id 10;}
bridge-domains {bd0 {service-id 2;}}
routing-instances {r1 {switch-options {service-id 10;}bridge-domains {bd0 {service-id 2;}}}}

Logical Systems

ls1 {switch-options {service-id 10;}routing-instances {r1 {switch-options {service-id 10;}}}}

Note: Using a service name per bridge domain is not supported.

The bridge-level service ID is required to link related bridge domains across peers, and should be configured with the same value. The service-id values share the name space across all bridging and routing instances, and across peers. Thus, duplicate values for service IDs are not permitted across these entities.

The service ID at the bridge domain level is mandatory for type non-single VLAN bridge domains. The service ID is optional for bridge domains with a VID defined. If no service ID is defined in the latter case, it is picked up from the service ID configuration for that routing instance.

Note: When this default routing instance (or any other routing instance) which contains a bridge domain containing an multichassis aggregated Ethernet interface is configured, you must configure a global level switch-options service-id number, irrespective of whether the contained bridge domains have specific service IDs configured.

In the sample illustration shown in Figure 1, network routing instances N1 and N2, both for the same service ID, are configured with same service-ID in both N1 and N2. Use of a name string instead of a number is not supported.

Figure 1: N1 and N2 for the Same Service with Same Service ID

N1 and N2 for the Same Service with Same
Service ID

The following configuration restrictions apply:

  • The service ID must be configured when the multichassis aggregated Ethernet interface is configured and a multichassis aggregated Ethernet logical interface is part of a bridge domain. This requirement is enforced.
  • A single bridge domain cannot correspond to two redundancy group IDs.

    In Figure 2, it is possible to configure a bridge domain consisting of logical interfaces from two multichassis aggregated Ethernet interfaces and map them to a separate redundancy group ID, which is not supported. A service must be mapped one-to-one with the redundancy group providing the service. This requirement is enforced.

    Figure 2: Bridge Domain with Logical Interfaces from Two Multichassis Aggregated Ethernet Interfaces

    Bridge Domain
with Logical Interfaces from Two Multichassis Aggregated Ethernet

To display the multichassis aggregated Ethernet configuration, use the show interfaces mc-ae command. For more information, see the CLI Explorer.

Configuring IGMP Snooping for Active-Active MC-LAG

For the multicast solution to work, the following must be configured:

  • The multichassis protection link must be configured as a router-facing interface.
    [edit bridge-domain bd-name]
    protocols {igmp-snooping {interface ge-0/0/0.0 {multicast-router-interface;}}}

    In this example, ge-0/0/0.0 is an ICL interface.

  • The multichassis-lag-replicate-state statement options must be configured under the multicast-snooping-options statement for that bridge domain.

Note: Snooping with active-active MC-LAG is only supported in non-proxy mode.

Published: 2015-02-23