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

IGMP Snooping in MC-LAG Active-Active on MX Series Routers Overview

IGMP Snooping in MC-LAG Active-Active on MX Series Routers Functionality

• State synchronization between peers for IGMP snooping in a bridge domain with only Layer 2 interfaces
• Qualified learning
• Router facing multichassis links

• MC-LAG support for IGMP snooping in a pure Layer 2 switch
• MC-LAG support for IGMP snooping in bridge domains doing qualified learning
• Support for MC-Links being router facing interfaces

• MC-LAG for VPLS instances
• MC-Links trunk ports
• Proxy mode for active-active
• Adding interchassis links to outgoing interfaces on an as needed basis. Interchassis links can be added to the outgoing interface list as router facing interfaces.

Typically Supported Network Topology for IGMP Snooping with MC-LAG Active-Active Bridging

Figure 1 depicts a typical network topology over which IGMP snooping with MC-LAG active-active is supported.

Figure 1: Typical Network Over Which Active-Active Is Supported

Interfaces I3 and I4 are single-homed interfaces. The multichassis links (MC-Link) ae0.0 and ae0.1 belong to the same bridge domain in both the chassis. Interfaces I3, ae0.0 and ae0.1 are in the same bridge domain in S-A. Interfaces I4, ae0.0 and ae0.1 are in the same bridge domain in the primary active (P-A) router. Interfaces I3, I4, ae0.0 and ae0.1 are in the same learning domain as is the interchassis link (ICL) connecting the two chassis.

The primary active router is the chassis in which the integrated routing and bridging has become PIM-DR. The secondary active router is the chassis in which integrated routing and bridging is not PIM DR. Router P-A is the chassis responsible for pulling traffic from the IP core. Hence, PIM-DR election is used to avoid duplication of data traffic.

Learning domains are described in Qualified Learning.

For the IGMP speakers (hosts and routers) in the learning domain, P-A and S-A together should appear as one device with interfaces I4, I3, ae0.0 and ae0.1.

No duplicate control packets should be sent on multichassis links, meaning the control packet should be sent through only one link.

Control Plane State Updates Triggered by Packets Received on Remote Chassis

The membership state in Layer 3 multicast routing is updated as a result of reports learned on remote legs of multichassis links and s-links attached to the remote chassis.

The membership state and routing entry in snooping is updated when reports are received on the remote legs of a multichassis link.

When reports are received on S-links attached to the remote chassis the membership state or routing entry in snooping is not updated.

The list of <s,g>s for which the state is maintained is the same in both the chassis under snooping as long as the outgoing interface lists involve only multichassis links.

Data Forwarding

This discussion assumes integrated routing and bridging on P-A is the PIM-DR. It pulls the traffic from sources in the core. Traffic might also come on Layer 2 interfaces in the bridge domain. For hosts directly connected to the P-A chassis, there is no change in the way data is delivered.

For delivering traffic to hosts connected to S-A (which is the non-DR) on the single-homed link like I3, we rely on interchassis link. The traffic that hits P-A is sent over ICL to S-A to be delivered to the links that have reported interests in s,g and the links that are router facing.

When ae0 leg in P-A goes down, the hosts connected to the multichassis link will receive traffic via ICL. In S-A, traffic received on ICL is sent to multichassis links in the outgoing interface list for which the ae counterpart in P-A is down.

Pure Layer 2 Topology Without Integrated Routing and Bridging

Figure 2 illustrates the chassis connecting to the PIM-DR is the primary active router and the other is the secondary active.

Figure 2: Layer 2 Configuration Without Integrated Routing and Bridging

Qualified Learning

In this application, interfaces I1, I2, I3, I4, I5, I6, I7, I8, I9 and I10 are single-homed interfaces. The multichassis links ae0.0 and ae0.1 belong to the same bridge domain in both the chassis. Interfaces I10, I1,I7,I3,I5, ae0.0 and ae0.1 are in same bridge domain, bd1 in P-A. Interfaces I9, I2,I8,I4,I6, ae0.0 and ae0.1 are in same bridge domain, bd1 in S-A.

• In Primary Active and S-A, qualified learning is ON in bd1.
• Interfaces I1,I2,I3, ae0.0 and I4 belong to vlan1, learning domain ld1.
• Interfaces I7,I8,I5, ae0.1 and I6 belong to vlan2, learning domain ld2.
• Interfaces I9 and I10 belong to vlan3, learning domain ld3.

For the IGMP speakers (hosts and routers) in the same learning domain ld1, P-A and S-A linked should appear to be one switch.

For the IGMP speakers (hosts and routers) in the same learning domain ld2, P-A and S-A linked should appear to be one switch.

Since there are no multichassis links in learning domain ld3, for the IGMP speakers (hosts and routers) in learning domain ld3, P-A and S-A will not appear to be one switch.

This discussion assumes interchassis link ICL1 corresponds to learning domain ld1 and interchassis link ICL2 corresponds to learning domain ld2.

Control packet flow is supported, with the exception of passing information to IRB.

Data Forwarding with Qualified Learning

This discussion assumes one learning domain (LD), ld1, and further assumes interface I1 on router P-A is connected to the PIM-DR in the learning domain and pulls the traffic from sources in the core.

For delivering traffic to hosts connected to router S-A (which is the non-DR) on the single-homed link like I2, I4 (belonging to ld1), we rely on ICL1. The traffic that hits router P-A on interface I1 is sent over interchassis link ICL1 to router S-A to be delivered to the links that have reported interests in s,g or the links that are router facing in learning domain ld1.

When the interface ae0 leg in router P-A goes down, the hosts connected to the multichassis link receive traffic from interface I1 via the interchassis link ICL1. In router S-A, traffic received on interchassis link ICL1 is sent to multichassis links in the outgoing interface list for which the aggregated Ethernet counterpart in router P-A is down.

It is further assumed that interface I9 in router S-A belongs to the learning domain ld3 with interests in s,g, and that interface I10 in learning domain ld3 in router P-A receives traffic for s,g. Interface I9 does not receive data in this topology because there are no multichassis links (in a-a mode) and hence no interchassis link in learning domain ld3.

Static Groups on Single Homed Interfaces

For multichassis links, the static group configuration should exist on both legs and synchronization with the other chassis is not required.

Synchronization of the static groups on single homed interfaces between the chassis is not supported, however the addition of logical interfaces to the default outgoing interface list supports traffic delivery to the interface within a static configuration.

Router Facing Interfaces as Multichassis Links

IGMP queries could arrive on either leg of the multichassis links but in both peers, the multichassis link should be considered as router facing.

Reports should exit only once from the multichassis link, that is from only one leg.

• Non-proxy snooping
• Logical interfaces must be outgoing interfaces for all routes including the default route
• IGMP snooping in a pure Layer 2 switch
• IGMP snooping in bridge domains doing qualified learning
• Router facing interface MC-Links

• Proxy mode for active-active
• MC-LAG support for VPLS instances
• Trunk ports as multichassis links
• Adding logical interfaces to outgoing interfaces on need basis. However, logical interfaces are always added as a router facing interface to the outgoing interface list.