Was this helpful?
Support for IGMP Snooping on VXLANs
In previous versions of software, Netvisor flooded IGMP multicast data traffic to all ports and tunnels in a VXLAN. In Version 3.1.1, Netvisor adds selective multicast flooding based on IGMP join messages received over ports and tunnels so multicast traffic received on a group sends traffic to only member ports and tunnels.
This feature uses the existing VXLAN implementation and uses head-end-replication (HER) model for replication packets to remote VTEPs. Netvisor sends IGMP join messages over tunnels for other switches to build the group member list.
Figure 1: Sample Toplogy
Configure Switch 1 and Switch 2 as a cluster pair and use a virtual IP address (VIP) as the source IP for the tunnels (T1 and T2) originating from the configuration. The cluster pair, Switch 3 and Switch 4, appears as one logical switch (VTEP1), and each creates a local tunnel, (T1 and T2), with the same local VIP though the topology displays the VIP in a logical fashion to follow through on the rest of the topology.
Configure Tunnels T1, T2 and T3 as unicast point-to-point tunnels. Netvisor OS sends tunnel traffic from Switch 3 or Switch 4 to the cluster pair, Switch 1 and Switch 2, where the Spine hashes the traffic to either Switch 1 or Switch 2.
Configure Switches 1, 2, 3, and 4 with ports 2,3,4,5, and 6, and as part of VXLAN 10.
Switch 4 sends IGMP join messages for the group, G1. Switch 3 adds Layer 2 multicast group G1 with P4 as an IGMP member.
Switch 3: G1 -> P4
Switch 3 floods IGMP packets to VTEPs 1 and 4. Switch 4 receives IGMP packets and adds a Layer 2 multicast group.
Switch 4: G1->VTEP3 (T3)
The spine switch hashes IGMP join messages from Switch 3 to Switch 1, and Switch 1 adds the Layer 2 multicast entry.
Switch 1: G1->VTEP3(T2)
Switch 1 notifies Switch 2 about an IGMP join message received on T2 by forwarding the IGMP join to the cluster peer through an out-of-band channel as currently performed for IGMP joins for VLAGs. After receiving the join, Switch 2 verifies that it has the same tunnel and programs the Layer 2 multicast entry.
Switch 2: G1->VTEP3(T2)
In the meantime, P6 joins G1, and the IGMP packets flood T1, and T3. Now the group membership changes to the following:
Switch 1: G1 -> VTEP4(T1), VTEP3,(T2)
Switch 2: G1 -> VTEP4(T1), VTEP3,(T2)
Switch 3: G1 -> P4, VTEP4(T3)
Switch 4: G1 -> P6, VTEP3(T3)
If a multicast source, S1, sends traffic on P3, traffic matching the MAC address corresponding to the G1 DMAC/VXLAN 10 in the Layer 2 table and then Netvisor OS bridges traffic to T1 and T2. After receiving traffic on G1 DMAC/VXLAN 10, Switch 3 and Switch 4 check the Layer 2 table and forwards the traffic to local receivers, P4 on Switch 3 and P6 on Switch 4.
The following command support this feature: