Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation

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:

[edit]interfaces {ae0 {encapsulation ethernet-bridge;multi-chassis-protection {peer 10.10.10.10 {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 ethernet-bridge or extended-vlan-bridge.

Use the mode statement to specify if a MC-LAG is active-standby or active-active. If the ICCP connection is UP and ICL comes UP, the router configured as standby will bring up the multichassis aggregated Ethernet (MC-AE) 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 the following assumption exists (follow the above example):

If there are n+1 logical interfaces under ae0, from ae0.0 through ae0.n, there will be 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 will be a protection link for the ae0 logical interface.

Note: A bridge domain cannot have MC-AE logical interfaces which belong to different redundancy groups.

Configuring Interchassis Link Label

Ethernet as interchassis link label (ICL-PL) (assumes interface ge-0/0/0.0 is used to protect interface ae0.0 of MC-LAG-1):

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

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

Configuring Multiple Chassis

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

[edit]multi-chassis {multi-chassis-protection {peer 10.10.10.10 {interface ge-0/0/0;}}}

The above example specifies interface ge-0/0/0 as the multichassis protection interface for all the multichassis aggregated Ethernet (MC-AE) 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 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

logical-system {ls1 {switch-options {service-id 10;}}}logical-system {ls1 {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 MC-AE 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 example 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 MC-AE interface is configured and an MC-AE logical interface is part of a bridge domain. This requirement is enforced.
  • A single bridge domain cannot correspond to two redundancy group IDs.

    Figure 2: Bridge Domain with Logical Interfaces from Two MC-AE Interfaces

    Bridge Domain
with Logical Interfaces from Two MC-AE Interfaces

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

To display the MC-AE configuration, use the show interfaces mc-ae command. For more information, see the Junos OS Interfaces Command Reference .

Configuring IGMP Snooping for Active-Active MC-LAG

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

  • The multichassis protection link should 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 should 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: 2012-06-26