The following sections provide an overview of the terms and features associated with MC-LAG:

• Active-Active and Active-Standby Modes
• ICCP and ICL
• LACP
• Data Traffic Forwarding Rules
• Multichassis Link Protection
• Failure Handling
• Load Balancing
• Layer 2 Unicast Features Supported
• Layer 2 Multicast Features Supported
• IGMP Snooping on an Active-Active MC-LAG
• Layer 3 Unicast Features Supported
• VRRP Active-Standby Support
• MAC Address Management
• MAC Address Synchronization and Replication
• Address Resolution Protocol Active-Active MC-LAG Support Methodology
• DHCP Relay with Option 82
• Protocol Independent Multicast
• MC-LAG Packet Forwarding
• Layer 3 Unicast Features Supported
• Spanning Tree Protocol Guidelines
• MC-LAG Upgrade
• Private VLANs

Load Balancing

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.

Layer 2 Unicast Features Supported

The following Layer 2 unicast features are supported:

Learning and aging

• Learned MAC addresses are propagated across MC-LAG peers for all of the VLANs that are spawned across the peers.
• Aging of MAC addresses occurs when the MAC address is not seen on both of the peers.
• MAC addresses learned on single-homed links are propagated across all of the VLANs that have MC-LAG links as members.

Note: 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.

Layer 2 Multicast Features Supported

The following Layer 2 multicast features are supported:

Unknown unicast and IGMP snooping

• Flooding happens on all links across peers if both peers have virtual LAN membership. Only one of the peers forwards traffic on a given MC-LAG link.
• Known and unknown multicast packets are forwarded across the peers by adding the ICL port as a multicast router port.
• IGMP membership learned on MC-LAG links is propagated across peers.
• During an MC-LAG peer reboot, known multicast traffic is flooded until the IGMP snooping state is synchronized with the peer.

IGMP Snooping on an Active-Active MC-LAG

Internet Group Management Protocol (IGMP) snooping controls multicast traffic in a switched network. When IGMP snooping is not enabled, the Layer 2 device broadcasts multicast traffic out of all of its ports, even if the hosts on the network do not want the multicast traffic. With IGMP snooping enabled, a Layer 2 device monitors the IGMP join and leave messages sent from each connected host to a multicast router. This enables the Layer 2 device to keep track of the multicast groups and associated member ports. The Layer 2 device uses this information to make intelligent decisions and to forward multicast traffic to only the intended destination hosts. IGMP uses Protocol Independent Multicast (PIM) to route the multicast traffic. PIM uses distribution trees to determine which traffic is forwarded.

In an active-active MC-LAG configuration, IGMP snooping replicates the Layer 2 multicast routes so that each MC-LAG peer has the same routes. If a device is connected to an MC-LAG peer by way of a single-homed interface, IGMP snooping replicates the join message to its IGMP snooping peer. If a multicast source is connected to an MC-LAG by way of a Layer 3 device, the Layer 3 device passes this information to the IRB or the routed VLAN interface (RVI) that is configured on the MC-LAG. The first hop designated router is responsible for sending the register and register-stop messages for the multicast group. The last hop designated router is responsible for sending PIM join and leave messages toward the rendezvous point and source for the multicast group. The routing device with the smallest preference metric forwards traffic on transit LANs.

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. For the scenario in which traffic arrives by way of a Layer 3 interface, PIM and IGMP must be enabled on the IRB or RVI interface configured on the MC-LAG peers. You must enable PIM on the IRB or RVI interface to avoid multicast duplication.

Layer 3 Unicast Features Supported

To provide Layer 3 routing functions to downstream clients, the MC-LAG network peers must be configured to provide the same gateway address to the downstream clients. To the upstream routers, the MC-LAG network peers could be viewed as either equal-cost multipath (ECMP) or two routes with different preference values.

The following two methods can be used to enable Layer 3 functionality across an MC-LAG. We recommend that you use the VRRP over IRB or RVI method. Use MAC address synchronization only when you cannot configure VRRP over an IRB or RVI.

• Configure different IP addresses on IRB or RVI interfaces, and run Virtual Router Redundancy Protocol (VRRP) over the IRB or RVI interfaces. The virtual IP address is the gateway IP address for the MC-LAG clients.
• Configure the MAC address synchronization feature using the mcae-mac-synchronize statement, and configure the same IP address on each of the IRB or RVI interfaces on the MC-LAG peers. This IP address is the gateway IP address for the MC-LAG clients.

Layer 3 unicast feature support includes the following:

• Address Resolution Protocol (ARP) synchronization enables ARP resolution on both of the MC-LAG peers.
• DHCP Relay with option 82 enables option 82 on the MC-LAG peers. Option 82 provides information about the network location of DHCP clients. The DHCP server uses this information to implement IP addresses or other parameters for the client.

VRRP Active-Standby Support

The Juniper Networks Junos operating system (Junos OS) supports active-active MC-LAGs by using VRRP in active-standby mode. VRRP in active-standby mode enables Layer 3 routing over the multichassis aggregated Ethernet interfaces on the MC-LAG peers. In this mode, the MC-LAG peers act as virtual routers. The peers share the virtual IP address that corresponds to the default route configured on the host or server connected to the MC-LAG. This virtual IP address (of the IRB or RVI interface) maps to either of the VRRP MAC addresses or to the logical interfaces of the MC-LAG peers. The host or server uses the VRRP MAC address to send any Layer 3 upstream packets. At any time, one of the VRRP devices is the master (active), and the other is a backup (standby). Usually, a VRRP backup node does not forward incoming packets. However, when VRRP over IRB or RVI is configured in an MC-LAG active-active environment, both the VRRP master and the VRRP backup forward Layer 3 traffic arriving on the interface. If the master fails, all the traffic shifts to the multichassis aggregated Ethernet interface on the backup.

Note: You must configure VRRP on both MC-LAG peers for both the active and standby members to accept and route packets. Additionally, you must configure the VRRP backup device to send and receive ARP requests.

Routing protocols run on the primary IP address of the IRB or RVI interface, and both of the MC-LAG peers run routing protocols independently. The routing protocols use the primary IP address of the IRB or RVI interface and the IRB or RVI MAC address to communicate with the MC-LAG peers. The IRB or RVI MAC address of each MC-LAG peer is replicated on the other MC-LAG peer and is installed as a MAC address that has been learned on the ICL.

Note: If you are using the VRRP over IRB or RVI method to enable Layer 3 functionality, you must configure static ARP entries for the IRB or RVI interface of the remote MC-LAG peer to allow routing protocols to run over the IRB or RVI interfaces.

MAC Address Management

• MAC addresses learned on an MC-LAG of one MC-LAG peer must be replicated as learned on the same MC-LAG of the other MC-LAG peer.
• MAC addresses learned on single-homed customer edge (CE) clients of one MC-LAG peer must be replicated as learned on the ICL interface of the other MC-LAG peer.
• MAC address learning on an ICL is disabled from the data path. It depends on software to install MAC addresses replicated through ICCP.

MAC Aging

MAC aging support in Junos OS extends aggregated Ethernet logic for a specified MC-LAG. A MAC address in software is not deleted until all Packet Forwarding Engines have deleted the MAC address.

MAC Address Synchronization and Replication

MAC address synchronization enables MC-LAG peers to forward Layer 3 packets arriving on multichassis aggregated Ethernet interfaces with either their own IRB or RVI MAC address or their peer’s IRB or RVI MAC address. Each MC-LAG peer installs its own IRB or RVI MAC address as well as the peer’s IRB or RVI MAC address in the hardware. Each MC-LAG peer treats the packet as if it were its own packet. If MAC address synchronization is not enabled, the IRB or RVI MAC address is installed on the MC-LAG peer as if it was learned on the ICL.

Note: If you are using MAC address synchronization to enable Layer 3 functionality, running routing protocols over the IRB or RVI interface is not supported. If you need routing capability, configure both VRRP and routing protocols on each MC-LAG peer.

MAC address replication, however, provides the ability to exchange learned Layer 2 MAC address information. If you have a VLAN without an IRB or RVI configured, MAC address replication will synchronize the MAC addresses.

Control packets destined for a particular MC-LAG peer that arrive on an multichassis aggregated Ethernet interface of its MC-LAG peer are not forwarded on the ICL interface. Additionally, using the gateway IP address as a source address when you issue either a ping, traceroute, telnet, or FTP request is not supported.

Note: Gratuitous ARP requests are not sent when the MAC address on the IRB or RVI interface changes.

In a VLAN that requires Layer 3 functionality and MAC address synchronization, you can configure either VRRP over an IRB or RVI interface or configure MAC address synchronization. MAC address synchronization requires you to configure the same IP address on the IRB interface in the VLAN on both MC-LAG peers. To enable the MAC address synchronization feature using the standard CLI, issue the set vlan vlan-name mcae-mac-synchronize command on each MC-LAG peer. If you are using the Enhanced Layer 2 CLI, issue the set bridge-domains name mcae-mac-synchronize command on each MC-LAG peer. Configure the same IP address on both MC-LAG peers. This IP address is used as the default gateway for the MC-LAG servers or hosts.

Address Resolution Protocol Active-Active MC-LAG Support Methodology

Address Resolution Protocol (ARP) maps IP addresses to MAC addresses. Junos OS uses ARP response packet snooping to support active-active MC-LAGs, providing easy synchronization without the need to maintain any specific state. Without synchronization, if one MC-LAG peer sends an ARP request, and the other MC-LAG peer receives the response, ARP resolution is not successful. With synchronization, the MC-LAG peers synchronize the ARP resolutions by sniffing the packet at the MC-LAG peer receiving the ARP response and replicating this to the other MC-LAG peer. This ensures that the entries in ARP tables on the MC-LAG peers are consistent.

When one of the MC-LAG peers restarts, the ARP destinations on its MC-LAG peer are synchronized. Because the ARP destinations are already resolved, its MC-LAG peer can forward Layer 3 packets out of the multichassis aggregated Ethernet interface.

Note: In some cases, ARP messages received by one MC-LAG peer are replicated to the other MC-LAG peer through ICCP. This optimization feature is applicable only for ARP replies, not ARP requests, received by the MC-LAG peers.

Note: Dynamic ARP resolution over the ICL interface is not supported. Consequently, incoming ARP 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.

Note: During graceful Routing Engine switchover (GRES), ARP entries that were learned remotely are purged and then learned again.

DHCP Relay with Option 82

Note: DHCP relay is not supported with MAC address synchronization. If DHCP relay is required, configure VRRP over IRB or RVI for Layer 3 functionality.

DHCP relay with option 82 provides information about the network location of DHCP clients. The DHCP server uses this information to implement IP addresses or other parameters for the client. With DHCP relay enabled, DHCP request packets might take the path to the DHCP server through either of the MC-LAG peers. Because the MC-LAG peers have different host names, chassis MAC addresses, and interface names, you need to observe these requirements when you configure DHCP relay with option 82:

• Use the interface description instead of the interface name.
• Do not use the hostname as part of the circuit ID or remote ID string.
• Do not use the chassis MAC address as part of the remote ID string.
• Do not enable the vendor ID.
• If the ICL interface receives DHCP request packets, the packets are dropped to avoid duplicate packets in the network.

  A counter called Due to received on ICL interface has been added to the show helper statistics command, which tracks the packets that the ICL interface drops.

  An example of the CLI output follows:

  user@switch> show helper statistics

  BOOTP:
    Received packets: 6
    Forwarded packets: 0
    Dropped packets: 6
      Due to no interface in DHCP Relay database: 0
      Due to no matching routing instance: 0
      Due to an error during packet read: 0
      Due to an error during packet send: 0
      Due to invalid server address: 0
      Due to no valid local address: 0
      Due to no route to server/client: 0
      Due to received on ICL interface: 6
  

  The output shows that six packets received on the ICL interface have been dropped.

Protocol Independent Multicast

Protocol Independent Multicast (PIM) and Internet Group Management Protocol (IGMP) provide support for Layer 3 multicast. In addition to the standard mode of PIM operation, there is a special mode called PIM dual DR (designated router). PIM dual DR minimizes multicast traffic loss in case of failures.

PIM operation is discussed in the following sections:

• PIM Operation with Normal Mode Designated Router Election
• PIM Operation with Dual Designated Router Mode

PIM Operation with Normal Mode Designated Router Election

In normal mode designated router election, the IRB or RVI interfaces on both of the MC-LAG peers are configured with PIM enabled. In this mode, one of the MC-LAG peers becomes the designated router through the PIM designated router election mechanism. The elected designated router maintains the rendezvous-point tree (RPT) and shortest-path tree (SPT) so it can receive data from the source device. The elected designated router participates in periodic PIM join and prune activities toward the rendezvous point (RP) or the source.

The trigger for initiating these join and prune activities is the IGMP membership reports that are received from interested receivers. IGMP reports received over multichassis aggregated Ethernet interfaces (potentially hashing on either of the MC-LAG peers) and single-homed links are synchronized to the MC-LAG peer through ICCP.

Both MC-LAG peers receive traffic on their incoming interface (IIF). The non-designated router receives traffic by way of the ICL interface, which acts as a multicast router (mrouter) interface.

If the designated router fails, the non-designated router has to build the entire forwarding tree (RPT and SPT), which can cause multicast traffic loss.

PIM Operation with Dual Designated Router Mode

In dual designated router (DR) mode, both of the MC-LAG peers act as designated routers (active and standby) and send periodic join and prune messages upstream toward the RP, or source, and eventually join the RPT or SPT.

The primary MC-LAG peer forwards the multicast traffic to the receiver devices even if the standby MC-LAG peer has a smaller preference metric.

The standby MC-LAG peer also joins the forwarding tree and receives the multicast data. The standby MC-LAG peer drops the data because it has an empty outgoing interface list (OIL). When the standby MC-LAG peer detects the primary MC-LAG peer failure, it adds the receiver VLAN to the OIL, and starts to forward the multicast traffic.

To enable a multicast dual DR, issue the set protocols pim interface interface-name dual-dr command on the VLAN interfaces of each MC-LAG peer.

MC-LAG Packet Forwarding

To prevent the server from receiving multiple copies from both of the MC-LAG peers, a block mask is used to prevent forwarding of traffic received on the ICL toward the multichassis aggregated Ethernet interface. Preventing forwarding of traffic received on the ICL interface toward the multichassis aggregated Ethernet interface ensures that traffic received on MC-LAG links is not forwarded back to the same link on the other peer. The forwarding block mask for a given MC-LAG link is cleared if all of the local members of the MC-LAG link go down on the peer. To achieve faster convergence, if all local members of the MC-LAG link are down, outbound traffic on the MC-LAG is redirected to the ICL interface on the data plane.

Layer 3 Unicast Features Supported

To provide Layer 3 routing functions to downstream clients, the MC-LAG network peers must be configured to provide the same gateway address to the downstream clients. To the upstream routers, the MC-LAG network peers could be viewed as either equal-cost multipath (ECMP) or two routes with different preference values.

The following two methods can be used to enable Layer 3 functionality across an MC-LAG. We recommend that you use the VRRP over IRB or RVI method. Use MAC address synchronization only when you cannot configure VRRP over the IRB or RVI interface.

• Configure different IP addresses on IRB or RVI interfaces, and run Virtual Router Redundancy Protocol (VRRP) over the IRB or RVI interfaces. The virtual IP address is the gateway IP address for the MC-LAG clients.
• Configure the MAC address synchronization feature using the mcae-mac-synchronize statement,and configure the same IP address on each of the IRBs or RVIs on the MC-LAG peers. This IP address is the gateway IP address for the MC-LAG clients.

If you are using the VRRP over IRB method to enable Layer 3 functionality, you must configure static ARP entries for the IRB interface of the remote MC-LAG peer to allow routing protocols to run over the IRB interfaces. This step is required so you can issue the ping command to reach both the physical IP addresses and virtual IP addresses of the MC-LAG peers.

For example, you can issue set interfaces irb unit 18 family inet address 10.181.18.3/24 arp 10.181.18.2 mac 84:18:88:96:2f:f0 command.

When you issue the show interfaces irb command after you have configured VRRP over IRB, you will see that the static ARP entries are pointing to the IRB MAC addresses of the remote MC-LAG peer:

Physical interface: irb, Enabled, Physical link is Up
  Interface index: 180, SNMP ifIndex: 532
  Type: Ethernet, Link-level type: Ethernet, MTU: 1514
  Device flags   : Present Running
  Interface flags: SNMP-Traps
  Link type      : Full-Duplex
  Link flags     : None
  Current address: 84:18:88:96:2f:f0, Hardware address: 84:18:88:96:2f:f0
  Last flapped   : Never
    Input packets : 0 
    Output packets: 0

Layer 3 unicast feature support includes the following:

• Address Resolution Protocol (ARP) synchronization enables ARP resolution on both of the MC-LAG peers.

• DHCP Relay with option 82 enables option 82 on the MC-LAG peers. Option 82 provides information about the network location of DHCP clients. The DHCP server uses this information to implement IP addresses or other parameters for the client.

Spanning Tree Protocol Guidelines

The Spanning Tree Protocol (STP) guidelines are as follows:

• Enable STP globally.

  STP might detect local miswiring loops within the peer or across MC-LAG peers.

  STP might not detect network loops introduced by MC-LAG peers.

• Disable STP on ICL links; otherwise, STP might block ICL interfaces and disable protection.
• Disable STP on interfaces that are connected to aggregation switches.
• 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

Upgrade the MC-LAG peers according to the following guidelines.

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.

1. Make sure that both of the MC-LAG peers (node1 and node2) are in the active-active state by using the following command on any one of the MC-LAG peers:
   user@switch> show interfaces mc-ae id 1

   Member 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
   

2. 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.

3. Verify that node1 is running the software you just installed by issuing the show version command.
4. Make sure that both nodes of the MC-LAG (node1 and node2) are in the active-active state after the reboot of node1.
5. Upgrade node2 of the MC-LAG.

   Repeat Step 1 through Step 3 to upgrade node2.

Private VLANs

Private VLANs (P-VLANs) allow you to split a broadcast domain into multiple isolated broadcast subdomains, essentially putting a VLAN inside of a VLAN. A P-VLAN can span multiple peers on an MC-LAG.

When configuring a P-VLAN, you must configure the ICL interface as the P-VLAN trunk interface for the P-VLAN. This is essential for traffic to be switched to the required primary and secondary ports of the P-VLAN across the MC-LAG peers.