Symptoms:
IPV6 Neighbor Discovery packets or Multicast Packets with destination MAC as multicast MAC is dropped at the receiver VNIC.
Using the drop filter, check if the packet is dropped on the switch port corresponding to the destination VM.
pktcap-uw --switchport <switchport> --capture DROP
Run the below command on the ESX host where the problem VM is located.
Non-Working VM:
[1]: 0x0
[1]: 0x0
}
For working VM:
ethFRP:frame routing {
requested:filter {
flags:0x0000000d -----------------------> The "0x0000000d" has VMK_ETH_FILTER_ALLMULTI flag.
unicastAddr:##:##:##:##:##:c4:
numMulticastAddresses:0
It depends on the number of multicast addresses enabled. If the total is less than 32, perform perfect filtering based on exact multicast address.
Otherwise, enable the allmulti flag so that all multicast address is received.
There are two main ways in which this ALLMULTI flag can be set.
(3.1) When multicast snooping is enabled, and the number of multicast addresses on a port > 512, ALLMULTI is set.
(3.2) ALLMULTI is set from the VM by vmxnet3 Linux driver. Looking at vmxnet3 Linux driver code, this happens in two cases:
(3.2.1) Explicit request to vmxnet3 driver to set ALLMULTI.
(3.2.2) If somehow the driver's attempt to pass an exact list of multicast addresses to the vmxnet3 device fails, ALLMULTI is set instead. When this happens, the following log entry should be found in dmesg when this happens: "failed to copy mcast list, setting ALL_MULTI"
Workaround:
(OR)
"ifconfig eth1 allmulti" on issue vms
Before setting allmulti on VM flags, it might be
eth1: flags <UP,BROADCAST,RUNNING,MULTICAST>
and after setting that, it might be
eth1: flags <UP, BROADCAST,RUNNING,ALLMUTICAST,MULTICAST>.
Then check whether the switchport status of vsish node is set as
ethFRP:frame routing {
requested:filter {
flags:0x0000000d