IGMPv3 Specific membership queries triggered when a VM leaves a multicast group are dropped by VDS
Article ID: 338285
Updated On:
Products
Issue/Introduction
This article is to explain a known issue with Multicast Source-Specific messages that are dropped.
Some configurations work around this issue by allowing all multicast packets but in environments where a large amount of multicast traffic is seen more filtering is needed. IGMP, Snooping/SSM
Symptoms:
Group-Specific Queries are sent when a router receives a State-Change record indicating a system is leaving a group.
- VM's do not receive the router queries to update Multicast tables accordingly
- IGMPv3 Specific Query --- not dropped by vDS
- IGMPv3 SSM Specific Query -- dropped by vDS
Iperf command produces an IGMPv3 SSM (Source-Specific Multicast) join. When one of the clients Leaves, the physical switch responds with an SSM Specific Query. That is what is being dropped.
Environment
VMware vSphere ESXi 7.0.0
Cause
ESXi does not treat SSM group-specific queries with src IP 0.0.0.0 correctly, no matter the mode.
Some physical switches like Dell/Cisco, rely on the IGMPv3 group-specific query to make sure there is still a port subscribed to a specific group or not when receiving a leave report.
Resolution
This is fixed in vSphere 6.7 p06 and 7.0.3
The fix makes IGMPv3 group-specific queries have the same code logic
as a general query to leverage legacy lookup to dispatch, in this way,
as long as the VNIC joins a group, the group's specific query will be
dispatched to this VNIC.
Workaround:
To work around this issue allowing all multicast to the specific vnic should be configured
Note: Additional traffic load will be sent to the VM increasing CPU. This may not be a suitable workaround in environments with large amounts of multicast traffic.
Linux
'ifconfig ethX allmulti'
for vmxnet3 driver.
[root@HOST:~] vsish -e get /net/portsets/DvsPortset-0/ports/67108870/status | grep -i flags
flags:port flags: 0x40013 -> IN_USE ENABLED WORLD_ASSOC CONNECTED ASSOCIATE_TO_L2_CTRL
Impl customized blocked flags:0x00000000
flags:0x0000000b
flags:0x0000000b
[root@ Virtual Machine ~]# ifconfig ens192 allmulti
[root@HOSTi:~] vsish -e get /net/portsets/DvsPortset-0/ports/67108870/status | grep -i flags
flags:port flags: 0x40013 -> IN_USE ENABLED WORLD_ASSOC CONNECTED ASSOCIATE_TO_L2_CTRL
Impl customized blocked flags:0x00000000
flags:0x0000000d
flags:0x0000000d
Windows
Enabled. The computer can forward multicast packets.
Disabled. The computer cannot forward multicast packets.
Additional Information
To Reproduce this issue
[root@HOST:~] net-stats -l | grep -i VM
67108874 5 9 DvsPortset-0 00:50:56:b7:8d:4b VM.eth0
67108875 5 9 DvsPortset-0 00:50:56:b7:b5:ef VM.eth0
[root@HOST:~] netdbg vswitch mcast_filter get --port 67108875 --dvs-alias Multicast-vDS
1. Multicast clients VM-1 and VM-2 both join the SSM group:
#iperf -s -B MulticastIP -H VM-IP -u -f m -i 5
Note: This is only supported in Iperf2 for this protocol
2. Wait 5 seconds for each client to send 2-3 join packets
3. Make CentOS-1 leave the group:
Remove Iperf
#Ctrl + C
4. The multicast router receives the Leave Request, and responds with several Specific Queries (from Dell and Cisco switches) and a Group-and-Source Specific Query (from Cisco switch) to see if there are any multicast clients left on that physical switch port:
5. ESXi correctly removes VM-1 from the group, and VM-2 remains in the group:
Feedback
