Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Active-Active Bridging and VRRP over IRB Functionality on MX Series Routers Overview

MX Series routers support active-active bridging and virtual router redundancy protocol (VRRP) over Integrated routing and bridging (IRB). This is a common scenario used in data centers. This section provides an overview of the supported functionality.

• Interchassis link (ICL) pseudowire interface or Ethernet interface (ICL-PL field) for active-active bridging
• Active-active bridging
• VRRP over IRB for active-active bridging
• A single bridge domain cannot correspond to two redundancy group IDs

• Aggregated Ethernet (AE)
• Interchassis link (ICL)
• Multichassis link (MCL)

Figure 1: Single Multichassis Link

Figure 2: Dual Multichassis Link

• Virtual private LAN service (VPLS) within the core
• Bridged core
• Topology as described in Rule 4 of Data Traffic Forwarding Rules
• Routed multichassis aggregated Ethernet (RMC-AE), where the VRRP backup master is used in the edge of the network
• Track object, where in the case of an MC-LAG, the status of the uplinks from the provider edge can be monitored and the MC-LAG can act on the status
• Mixed mode (active-active MC-LAG is supported on MX series routers with MPC/MIC interfaces only). All interfaces in the bridge-domain that are mc-ae active-active, must be on MPC/MICs.

The topologies shown in Figure 3, Figure 4 and Figure 5 are not supported:

Figure 3: Interchassis Data Link Between Active-Active Nodes

Figure 4: Active-Active MC-LAG with Single MC-LAG

Figure 5: Active-Active MC-LAG with Multiple Nodes on a Single Multichassis Link

Note: A redundancy group cannot span more than two routers.

• Traffic received on the MC-LAG from one MC-LAG network device could be looped back to the same MC-LAG on the other MC-LAG network device.
• Duplicated packets could be received by the MC-LAG client device.
• Traffic could be unnecessarily forwarded on the interchassis link.

• Traffic received on network routing instance N1 from MCL1 could be flooded to ICL to reach network routing instance N2. Once it reaches network routing instance N2, it could be flooded back to MCL1.
• Traffic received on interface ge-0/0/0.0 could be flooded to MCL1 and ICL on network routing instance N1. Once network routing instance N2 receives such traffic from ICL, it could be again flooded to MCL1.
• If interface ge-1/0/0.0 does not exist on network routing instance N2, traffic received from interface ge-0/0/0.0 or MCL1 on network routing instance N1 could be flooded to network routing instance N2 through ICL unnecessarily since interface ge-0/0/0.0 and MCL1 could reach each other through network routing instance N1.

Figure 6: MC-LAG Device and Single-Homed Client

Data Traffic Forwarding Rules

Based on incoming and outgoing interface types, some constraints are added to the Layer 2 forwarding rules for MC-LAG configurations, as described in the data traffic forwarding rules. Note that if only one of the MC-LAG member link is in the UP state, it is considered an S-Link.

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

2. Note: The functionality described in rule 2 is not supported.

   The following circumstances determine whether or not an ICL receives a packet from a local MC-Link or S-Link:

   1. If the peer MC-LAG network device has S-Links or MC-LAGs that do not reside on the local MC-LAG network device.
   2. Whether or not interfaces on two peering MC-LAG network devices are allowed to talk to each other.
   Only if both a. and b. are true, is traffic always forwarded to the ICL.
3. 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 that the packet comes from.

4. Note: The topology shown in Figure 7 is not supported.

   In certain cases, for example the topology shown in Figure 7, there could be a loop caused by the ICL. To break the loops, one of the following mechanisms could be used:

   1. Run certain protocols, such as spanning tree protocol (STP). In this case, whether packets received on one ICL are forwarded to other ICLs is determined by using Rule 3.
   2. Configure the ICL to be fully meshed among the MC-LAG network devices. In this case, traffic received on the ICL would be not be forwarded to any other ICLs.
   In either case, duplicate packets could be forwarded to the MC-LAG clients. Consider the topology shown in Figure 7, where if network routing instance N1 receives a packet from ge-0/0/0.0, it could be flooded to ICL1 and ICL3.

   When receiving from ICL1 and ICL3, network routing instances N3 and N2 could flood the same packet to MCL2, as shown in Figure 7. To prevent this from happening, the ICL designated forwarder should be elected between MC-LAG peers and traffic received on an ICL could be forwarded to the active-active MC-LAG client by the designated forwarder only.

   Figure 7: Loop Caused by the ICL Links

   
5. When received from an ICL, traffic should not be forwarded to the core-facing client link connection between two provider edge (PE) devices (C-Link) if the peer chassis's (where the traffic is coming from) C-Link is UP.

MAC Address Management

• MAC addresses learned on a MC-LAG of one MC-LAG network device should be replicated as learned on the same MC-LAG of the peer MC-LAG network device.
• MAC addresses learned on single-homed customer edge (CE) clients of one MC-LAG network device should be replicated as learned on ICL-PL interface of the peer MC-LAG network device.
• MAC addresses learned on MC-LAG VE clients of one MC-LAG network device should be replicated as learned on the corresponding VE interface of the peer MC-LAG network device.
• MAC address learning on an ICL is disabled from the data path. It depends on software to install MAC addresses replicated through interchassis control protocol (ICCP).

MAC Aging

MAC aging support in the Junos OS extends aggregated Ethernet logic for a specified MC-LAG. A MAC address in software is deleted until all Packet Forwarding Engines have deleted the MAC address. In the case of an MC-LAG, a remote provider edge is treated as a remote Packet Forwarding Engine and has a bit in the MAC data structure.

Layer 3 Routing

In general, when an MC-LAG is configured to provide Layer 3 routing functions to downstream clients, the MC-LAG network peers should 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 multi path (ECMP) or two routes with different preference values.

Junos OS supports active-active MC-LAGs by using VRRP over IRB. Junos OS also supports active-active MC-LAGs by using IRB MAC address synchronization. You must configure IRB using the same IP address across MC-LAG peers. IRB MAC synchronization is supported on 32-bit interfaces and interoperates with earlier MPC/MIC releases.

To ensure that Layer 3 operates properly, instead of dropping the Layer 3 packet, the VRRP slave attempts to perform routing functions if the packet is received on an MC-LAG. A VRRP slave sends and responds to address resolution protocol (ARP) requests.

For ARP, the same issue exists as with Layer 2 MAC addresses. Once ARP is learned, it must be replicated to the MC-LAG through ICCP. The peer must install an ARP route based on the ARP information received through ICCP.

For ARP aging, ARP requests on the MC-LAG peers can be aged out independently.

Address Resolution Protocol Active-Active MC-LAG Support Methodology

Suppose one of the PE routers issues an ARP request and another PE router gets the response and, because of the aggregated Ethernet distribution logic, the ARP resolution is not successful. Junos OS uses ARP response packet snooping to perform active-active multichassis link aggregation group support, providing easy synchronization without the need to maintain any specific state.

IGMP Snooping on Active-Active MC-LAG

For multicast to work in an active-active MC-LAG scenario, the typical topology is as shown in Figure 8 and Figure 9 with interested receivers over S-links and MC-Links. Starting in Junos OS Release 11.2, support is extended for sources connected over Layer 2 interface.

If an MC-LAG is configured to be active-active, reports from MC-LAG clients could reach any of the MC-LAG network device peers. Therefore the IGMP snooping module needs to replicate the states such that the Layer 2 multicast route state on both peers are the same. Additionally for S-Link clients, snooping needs to replicate these joins to its snooping peer, which in the case of Layer 3 connected source, passes this information to the PIM on IRB to enable the designated router to pull traffic for these groups,

The ICL should be configured as a router facing interface. For the scenario where traffic arrives via a Layer 3 interface, it is a requirement to have PIM and IGMP enabled on the IRB interface configured on the MC-LAG network device peers.

Figure 8: Multicast Topology with Source Connected via Layer 3

With reference to Figure 8, either N1 or N2 becomes a designated router (for this example, N1 is the designated router). Router N1 would therefore pull the multicast traffic from the core. Once multicast data hits the network device N1, the data is forwarded based on the snooping learned route.

For MC-Link clients, data is forwarded via N1. In the case of failover of the MC-Links, the data reaches the client via N2. For S-Link clients on N1, data would be forwarded via normal snooping routes.

For S-Link clients on N2, data is forwarded via the ICL interface. Layer 2 multicast routes on N1 do not show these groups unless there is interest for the same group over MC-Links or over S-Links on N1. For IRB scenario, the IGMP membership and Layer 3 multicast route on N1 does however show these groups learned over the IRB interface.

Therefore, for a case where a specific group interest is only on the S-Link on N2, data arriving on N1 reaches N2 via the default route and the Layer 2 multicast route on N2 has the S-Link in the outgoing interface list.

Figure 9: Multicast Topology with Source Connected via MC-Link

In Figure 9, MCL1 and MCL2 are on different devices and the multicast source or IGMP querier is connected via MCL2. The data forwarding behavior seen is similar to that explained for multicast topology with source connected via Layer 3.

Note: IGMP snooping should not be configured in proxy mode. There should be no IGMP hosts or IGMP/PIM routers sitting on the ICL interface.

Up and Down Event Handling

1. If the interchassis control protocol (ICCP) connection is UP but the ICL interface becomes DOWN, the router configured as standby will bring down all the multichassis aggregated Ethernet interfaces shared with the peer which is connected to ICL. This will make sure that there are no loops in the network. Otherwise, both PEs will becomes PIM designated routers and, hence, forward multiple copies of the same packet to the customer edge.
2. If the ICCP connection is UP and the ICL comes UP, the router configured as standby will bring up the multichassis aggregated Ethernet interfaces shared with the peer.
3. If both the ICCP connection and the ICL are DOWN, the router configured as standby will bring up the multichassis aggregated Ethernet interfaces shared with the peer.
4. The layer 2 address learn daemon (l2ald) does not store the information about a MAC address learned from a peer in the kernel. If l2ald restarts, and if the MAC address was not learned from the local multichassis aggregated Ethernet interface, l2ald will clear the MAC addresses and this will cause the router to flood the packets destined to this MAC address. This behavior is similar to that in a Routing Engine switchover. (Please note that currently l2ald runs on a Routing Engine only when it is a master). Also, during the time l2ald is DOWN, ARP packets received from an ICCP peer will be dropped. ARP retry will take care of this situation. This will be the case with Routing Engine switchover too.
5. If ICCP restarts, l2ald will unremember the fact that a MAC address was learned from a peer and, if the MAC address was learned only from the peer, that MAC address will be deleted and the packets destined to this MAC address will be flooded.

Interchassis Control Protocol

Interchassis control protocol (ICCP) is used to sync configurations, states, and data.

• MC-LAG members and their operational states.
• Single-homed members and their operational states.

• MAC addresses learned and to be aged.
• ARP info learned over IRB.

Interchassis Control Protocol Message

ICCP messages and attribute-value pairs (AVPs) are used for synchronizing MAC address and ARP information.