Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Multichassis Link Aggregation Overview

    Layer 2 networks are increasing in scale mainly because of technologies such as virtualization. Protocol and control mechanisms that limit the disastrous effects of a topology loop in the network are necessary. The Spanning Tree Protocol (STP) is the primary solution to this problem because it provides a loop-free Layer 2 environment. STP has gone through a number of enhancements and extensions, and even though it scales to very large network environments, it still only provides one active path from one device to another, regardless of how many actual connections might exist in the network. Although STP is a robust and scalable solution to redundancy in a Layer 2 network, the single logical link creates two problems: At least half of the available system bandwidth is off-limits to data traffic, and network topology changes occur. Rapid Spanning Tree Protocol (RSTP) reduces the overhead of the rediscovery process and allows a Layer 2 network to reconverge faster, but the delay is still high.

    Link aggregation (IEEE 802.3ad) solves some of these problems by enabling users to use more than one link connection between switches. All physical connections are considered one logical connection. The problem with standard link aggregation is that the connections are point to point.

    Multichassis link aggregation groups (MC-LAGs) enable a client device to form a logical LAG interface between two MC-LAG peers. 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 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 uses the link as a LAG. On the other side of the 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.

    Link Aggregation Control Protocol (LACP) is a subcomponent of the IEEE 802.3ad standard. LACP is used to discover multiple links from a client device connected to an MC-LAG peer. LACP must be configured on both MC-LAG peers for an MC-LAG to work correctly.

    Note: You must specify a service identifier (service-id) for each multichassis aggregated Ethernet interface that belongs to a LAG; otherwise, multichassis link aggregation will not work.

    Features Supported on the EX Series, MX Series, and QFX Series

    Table 1 lists the MC-LAG features supported on the EX Series Ethernet Switches, MX Series 3D Universal Edge Routers, and the QFX Series.

    Table 1: Feature Support on the EX Series, MX Series, and QFX Series

    Features

    EX4300 Device

    EX4600 Device

    EX9200 Device

    MX Series Devices

    QFX Series Devices

    Active-active bridging domain

    Not supported

    Not supported

    Not supported

    Supported

    Not supported

    Active-active mode

    Supported

    Supported

    Supported

    Supported

    Supported

    Active-standby mode

    Not supported

    Not supported

    Supported

    Supported

    Not supported

    Address Resolution Protocol (ARP) synchronization

    Supported

    Supported

    Supported

    Supported

    Supported

    Dynamic Host Control Protocol (DHCP) relay

    Supported

    Supported

    Supported

    Supported

    Supported

    Inter-Chassis Control Protocol (ICCP) and interchassis link (ICL)

    Supported

    Supported

    Supported

    Supported

    Supported

    Internet Group Management Protocol (IGMP)

    Supported

    Supported

    Supported

    Supported

    Supported

    IGMP snooping

    Supported

    Supported

    Supported

    Supported

    Supported

    Layer 2 circuit functions

    Not supported

    Not supported

    Supported

    Not supported

    Supported

    Link Aggregation Control Protocol (LACP)

    Supported

    Supported

    Supported

    Supported

    Supported

    Media access control (MAC) management

    Supported

    Supported

    Supported

    Supported

    Supported

    MAC address synchronization

    Supported

    Supported

    Not supported

    Supported

    Supported

    Multichassis link protection

    Supported

    Supported

    Supported

    Supported

    Supported

    Protocol Independent Multicast (PIM)

    Supported

    Supported

    Supported

    Supported

    Supported

    Pseudowire status type

    Not supported

    Not supported

    Not supported

    Not supported

    Supported

    Virtual private LAN service (VPLS)

    Not supported

    Not supported

    Not supported

    Supported in active-standby mode only

    Not supported

    Virtual Router Redundancy Protocol (VRRP)

    Supported

    Supported

    Supported

    Supported

    Supported

    Private VLANs (P-VLANS)

    Not supported

    Supported

    Not supported

    Not supported

    Supported

    Active-Active and Active-Standby Modes

    In active-active mode, all member links are active on the MC-LAG. In this mode, media access control (MAC) addresses learned on one MC-LAG peer are propagated to the other MC-LAG peer.

    In active-standby mode, only one of the MC-LAG peers is active at any given time. The other MC-LAG peer is in backup (standby) mode. The active MC-LAG peer uses Link Aggregation Control Protocol (LACP) to advertise to client devices that its child link is available for forwarding data traffic.

    Note: Active-standby mode is not supported on QFX Series switches and the EX4300 switch.

    ICCP and ICL

    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. ICCP replicates control traffic and forwarding states across the MC-LAG peers and communicates the operational state of the MC-LAG members. Because ICCP uses TCP/IP to communicate between the peers, the two peers must be connected to each other. ICCP messages exchange MC-LAG configuration parameters and ensure that both peers use the correct LACP parameters.

    The interchassis link (ICL), also known as the interchassis link-protection link (ICL-PL), is used to forward data traffic across the MC-LAG peers. This link provides redundancy when a link failure (for example, an MC-LAG trunk failure) occurs on one of the active links. The ICL can be a single physical Ethernet interface or an aggregated Ethernet interface. You can configure only one ICL between the two MC-LAG peers, although you can configure multiple MC-LAGs between them.

    LACP

    LACP is a subcomponent of the IEEE 802.3ad standard. LACP is used to discover multiple links from a client device connected to an MC-LAG peer. LACP must be configured on all member links for an MC-LAG to work correctly.

    Data Traffic Forwarding Rules

    In active-active MC-LAG topologies, network interfaces are categorized into three interface types, as follows:

    • S-Links—Single-homed link (S-Link) terminating on an MC-LAG peer device
    • MC-Links—MC-LAG links
    • ICL—Interchassis link

    Depending on the incoming and outgoing interface types, some constraints are added to the Layer 2 forwarding rules for MC-LAG configurations. The following data traffic forwarding rules apply.

    Note: If only one MC-LAG member link is in the up state, it is considered an S-Link.

    • When an MC-LAG network receives a packet from a local MC-Link or S-Link, the packet is forwarded to other local interfaces, including S-Links and MC-Links based on the normal Layer 2 forwarding rules and on the configuration of the mesh-group and no-local-switching statements. If MC-Links and S-Links are in the same mesh group and their no-local-switching statements are enabled, the received packets are only forwarded upstream and not sent to MC-Links and S-Links.
    • The following circumstances determine whether or not an ICL receives a packet from a local MC-Link or S-Link:

      • If the peer MC-LAG network device has S-Links or MC-LAGs that do not reside on the local MC-LAG network device
      • Whether or not interfaces on two peering MC-LAG network devices are allowed to talk to each other
    • When an MC-LAG network receives a packet from the ICL, the packet is forwarded to all local S-Links and active MC-LAGs that do not exist in the MC-LAG network from which the packet was sent.

    Multichassis Link Protection

    Multichassis link protection provides link protection between the two MC-LAG peers that host an MC-LAG. If the ICCP connection is up and the ICL comes up, the peer configured as standby brings up the multichassis aggregated Ethernet interfaces shared with the peer. Multichassis protection must be configured on each MC-LAG peer that is hosting an MC-LAG.

    Failure Handling

    Configuring ICCP adjacency over aggregated links with child links on multiple FPCs mitigates the possibility of a split-brain state. A split-brain occurs when ICCP adjacency is lost between the MC-LAG peers. To work around this problem, enable backup liveness detection. With backup liveness detection enabled, the MC-LAG peers establish an out-of-band channel through the management network in addition to the ICCP channel.

    During a split-brain state, both active and standby peers change LACP system IDs. Because both MC-LAG peers change the LACP system ID, the customer edge (CE) device accepts the LACP system ID of the first link that comes up and brings down other links carrying different LACP system IDs. When the ICCP connection is active, both of the MC-LAG peers use the configured LACP system ID. If the LACP system ID is changed during failures, the server that is connected over the MC-LAG removes these links from the aggregated Ethernet bundle.

    When the ICL is operationally down and the ICCP connection is active, the LACP state of the links with status control configured as standby is set to the standby state. When the LACP state of the links is changed to standby, the server that is connected over the MC-LAG makes these links inactive and does not use them for sending data.

    Table 2 describes the different ICCP failure scenarios. The dash means that the item is not applicable.

    Table 2: ICCP Failure Scenarios

    ICCP Connection Status

    ICL Status

    Backup Liveness Peer Status

    Action on Multichassis Aggregated Ethernet Interface with Status Set to Standby

    Down

    Down or Up

    Not configured

    LACP system ID is changed to default value.

    Down

    Down or Up

    Active

    LACP system ID is changed to default value.

    Down

    Down or Up

    Inactive

    No change in LACP system ID.

    Up

    Down

    LACP state is set to standby. MUX state moves to waiting state.

    Configure the master-only statement on the IP address of the fxp0 interface for backup liveness detection, on both the master and backup Routing Engines, to ensure that the connection is not reset during GRES in the remote peer.

    For example, on the master Routing Engine:

    user@switch-re1 > show configuration interfaces fxp0 | display inheritance no-comments
    unit 0 {family inet {address 10.8.2.31/24;address 10.8.2.33/24 {master-only;}}}

    For example, on the backup Routing Engine:

    user@switch1-re1 > show configuration interfaces fxp0 | display inheritance no-comments
    unit 0 {family inet {address 10.8.2.32/24;address 10.8.2.33/24 {master-only;}}}

    The master Routing Engine services both 10.8.2.31 and 10.8.2.33. Configure 10.8.2.33 in a backup-liveness-detection configuration on the peer node.

    For example, on the backup Routing Engine:

    user@switch2 > show configuration protocols iccplocal-ip-addr 2.2.2.2;
    peer 1.1.1.1 {session-establishment-hold-time 50;redundancy-group-id-list 1;backup-liveness-detection {backup-peer-ip 10.8.2.33;}liveness-detection {minimum-interval 500;multiplier 3;single-hop;}}

    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, learning and aging, are supported:

    • 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, unknown unicast and IGMP snooping, are supported:

    • 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 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 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 multichassis aggregated Ethernet 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

    If an MC-LAG is configured to be active-active, upstream and downstream traffic could go through different MC-LAG peer devices. Because the MAC address is learned only on one of the MC-LAG peers, traffic in the reverse direction could be going through the other MC-LAG peer and flooding the network unnecessarily. Also, a single-homed client's MAC address is learned only on the MC-LAG peer that it is attached to. If a client attached to the peer MC-LAG network device needs to communicate with that single-homed client, then traffic would be flooded on the peer MC-LAG network device. To avoid unnecessary flooding, whenever a MAC address is learned on one of the MC-LAG peers, the address is replicated to the other MC-LAG peer. The following conditions are applied when MAC address replication is performed:

    • 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

    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 the 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:

    user@switch> show interfaces irb
    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.

    Modified: 2015-09-21