Hi,
At our company we have an issue that a VIP address isn't available for around 10 minutes periods and it occurs quite often, two times per hour. We have a kubernetes cluster and an IP of a pod is exposed by a kubernetes loadbalancer service. We use MetalLb to assign an external IP address to the service. During investigation it turned out that only the speaker on machine B replies to the ARP requests of the router for the VIP address and it sends back multiple replies:
- one reply contains the MAC of ens192 interface of machine B - it is on the external network
- one reply contains the MAC of eth1 of machine be - it is on the internal network
The router receives these replies at the same time. If the reply containing the MAC of eth1 is received last, then the router writes it to its table and the VIP address won't be available. At the next ARP request, if the router receives the reply containing the MAC of ens192, then the VIP address becomes available.
If ens192 interface is specified in the
L2Advertisement custom resource, then MetalLb only advertises the ens192 interface and the problem disappears. However, according to MetalLb documentation (
https://metallb.universe.tf/faq/), there is no need to configure interfaces, it should work without it.
Regards,
Florian