Duplicate MAC address on VIP

17 views
Skip to first unread message

Francesco Trebbi

unread,
Oct 26, 2022, 9:16:55 AM10/26/22
to metallb-users

We do have an environments with multiple VMs on vmware.

Metallb version = 0.9.5

 

[Problem statement]

If the VIP is stable on the same VM there is no issue but when the VIP moves for the first time to another VM the physical switch keep seeing the VIP associated with multiple MAC addresses (where the VIP has been moved) impeding the connectivity with the VIP.

 

[Investigation]

  • Only 1 workers is sending the ARP messages associated with the VIP

    • Confirmed with sudo /usr/sbin/tcpdump -ennqti ens192 \( arp or icmp \)

 

The node where the VIP is associated displays the ARP reply messages:

00:50:56:bc:a7:63 > ff:ff:ff:ff:ff:ff, ARP, length 60: Request who-has 10.5.32.40 (ff:ff:ff:ff:ff:ff) tell 10.5.32.40, length 46

00:50:56:bc:a7:63 > ff:ff:ff:ff:ff:ff, ARP, length 60: Reply 10.5.32.40 is-at 00:50:56:bc:a7:63, length 46

 

On all the other nodes there is no evidence of ARP reply on the eth interfaces even though the physical switch captures multiple MAC addresses associated with the same VIP.

 

  • If the VM2 interface is shutdown such MAC2 (that is wrongly perceived as associated with VIP) disappears from the physical switch

    • This may indicates there is a link between the interface behavior and what the vSwitch is propagating

  • If all the applications on VM2 are shutdown the MAC2 does not disappear from the physical switch

    • This should indicates the application is not involved in this issue

 

[Request]

Asked the customer to open a ticket to Vmware to investigate the input of the physical switch to confirm if any ARP reply are present. There is no arp reply not even on the vmware environment. 

Is there any specific vmware configuration that metallb supports? or does not support?

Promiscuous mode/MAC address changes/Forged transmits etc ?

 

Reply all
Reply to author
Forward
0 new messages