The corresponding MAC address is abnormal after VIP switching

[chengsir520]

Describe the bug A clear and concise description of what the bug is. Keepalive switch, after VIP drift, the MAC address corresponding to VIP remains the same as the previous machine's MAC address

To Reproduce Any steps necessary to reproduce the behaviour: arp -vn|grep 192.168.123.239 Command to check the corresponding situation of Mac

Expected behavior A clear and concise description of what you expected to happen.

Keepalived version v2.0.20

Distro (please complete the following information): bclinux.x86_64

Details of any containerisation or hosted service (e.g. AWS) If keepalived is being run in a container or on a hosted service, provide full details docker run

Configuration file: ! Configuration File for keepalived

global_defs { router_id LVS_3 }

vrrp_script checkhaproxy { script "/opt/check.sh" interval 1 weight -30 }

vrrp_instance VI_1 { state MASTER interface ens192 virtual_router_id 152 priority 80 unicast_src_ip 192.168.123.100 unicast_peer { 192.168.123.101 192.168.123.102 } advert_int 1 virtual_ipaddress { 192.168.123.239/16 } track_script { checkhaproxy }

}

A full copy of the configuration file, obfuscated if necessary to protect passwords and IP addresses

**Notify and track scripts**

If any notify or track scripts are in use, please provide copies of them

**System Log entries**

Full keepalived system log entries from when keepalived started

**Did keepalived coredump?**

If so, can you please provide a stacktrace from the coredump, using gdb.

**Additional context**
Add any other context about the problem here.

[pqarmitage]

Can you please explain what you mean by "the MAC address corresponding to VIP remains the same as the previous machine's MAC address". How and where are you observing that the MAC address remains the same? What does the command "ip address show" on each of the systems where you are running keepalived?

[chengsir520]

arp -a | grep VIP check the ARP information, the MAC address corresponding to VIP is the MAC address of the machine before switching

[pqarmitage]

keepalived sends gratuitous ARP messages when a vrrp instance transitions to master state, and this should cause the ARP tables the receive the broadcast message to update their ARP caches.

You should see entries like:

(VI_1) Sending/queueing gratuitous ARPs on eth0 for 192.168.123.239
Sending gratuitous ARP on eth0 for 192.168.123.239

in your log files.

On your system that takes over as master, you could try running: tcpdump -n -nn -vei ens192 arp and you should see the gratuitous ARP messages sent when it takes over as master. For example I see: 07:16:49.600582 02:a5:03:37:a0:1b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.123.239 (ff:ff:ff:ff:ff:ff) tell 192.168.123.239, length 28

You should also try running the tcpdump command on the system whose ARP cache is not being updated, to ensure that it is receiving the gratuitous ARP messages.

[chengsir520]

But why is it normal to check the ARP after VIP switching and see that the MAC address corresponding to VIP in the master is the previous Keepalive MAC, while checking in the backup is normal

[pqarmitage]

It isn't normal that the MAC address doesn't change in the ARP cache; I have run some tests and can see that the MAC address does change for me.

You will need to do some testing, as I have suggested above, to try and identify why the MAC address isn't updating on your systems.

[chengsir520]

The master node has been sending this request all along (239 is VIP) 09:25:55.663246 00:0c:29:5c:46:cd > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.123.239 (ff:ff:ff:ff:ff:ff) tell 192.168.123.239, length 28

[pqarmitage]

Yes, that is a gratuitous ARP message. So keepalived is behaving correctly. If the ARP cache is not updating on some of your systems, you will need to work out why.

I am closing this issue now since keepalived is behaving correctly.

[chengsir520]

thank