The destination MAC address of the first packet from source VM in IPv6 Neighbor Solicitation is modified in transit from 33:33:ff:01:xx:xx (sent by Src VM) to 33:33:fe:01:xx:xx (received by Dst VM). This MAC address change is done at the vswitch layer inside the ESXi host of Source VM. This change is done only for the first packet and then the switch learns the MAC address correctly
3.x, 4.x
When ARP suppression is enabled (by default), after receiving Neighbor Solicitation message from VM, vswitch checks with LCP (local control plane) for the destination mac address and when it receives no response, vswitch forwards the packet to the uplink of ESXi host after computing solicited node multicast mac address from target IPv6 address.
Here an issue is present in vswitch while computing the 3rd octet which is computed from 12th octet of Link Local Target IPv6 address resulting in incorrect SNMA (Solicited Node Multicast MAC Address). This 3rd octet should be set to "ff" as per RFC 2464
This is a known issue present in vswitch of ESXi while computing SNMA (Solicited Node Multicast Mac Address) for destination IPv6 address.
This issue is fixed with NSX releases 4.2.3.2, 4.2.4, 9.0.2, 9.1 to correct the behavior of modifying multicast MAC address in VDS.
The workaround available to mitigate the issue is to set "arp supression" disabled on ESXi host
Command to disable ARP Suppression on vswitch >> net-vdl2 --arp-suppression=disable
Command to enable ARP Suppression on vswitch >> net-vdl2 --arp-suppression=enable
Command to check if ARP Suppression is enabled or disabled on vswitch >> net-vdl2 --arp-suppression
Note : The command to disable "arp suppression" needs to be executed every time after ESXi host reboot as it does not persist after reboot