Re: [Keepalived-devel] Mac address issue.

[Quentin A. <qu...@ar...>]

Paul,

I have tried what you describe regarding interface on master being set
down, the backup takes over and sends gratuitous arp, the interface on
the master is set back up and it takes over as master again. For me, I
can see gratuitous arp messages then being sent.

Can you please provide a copy of your configurations so that we can try
and work out what is happening. Do the logs on the master state if is
sending gratuitous arps when it takes over as master again? Can you
please provide a copy of the logs from the master. Are you using 'ip
link set eth0 down/up' to down the interfaces, or are you doing it some
other way?

Re macvlans not being able to be created, can you try the following:

1. ip link add link eth0 vrrp.1 type macvlan mode private

2. See whether CONFIG_MACVLAN is y, n or m in the kernel configuration.
If it is m, is the macvlan module loaded? If it is n, then that
explains the problem. If is is m and the macvlan module is loaded, or
if it is y, then something strange is happening.

Quentin

On Wed, 2018-10-24 at 12:02 +0100, Paul Gildea wrote:
> Testing out keepalived operation as regard to mac addresses on
> failover (2.0.7), I think I found an issue? If I shut down the
> interface that VRRP is configured on (the current master) I can see a
> gratuitous arp being sent correctly over the network, so that when I
> ping from a client the mac address of the new master is shown when
> queried (the physical interfaces mac). 
> 
> However if I bring back up the original interface and that system
> becomes master again there is no gratuitous arp sent. So if I ping
> and query I can still see the mac address of the backup physical
> interface, when the mac should be updated to the new/previous
> master. 
> 
> This is not an issue if I am bringing up and down tracked interfaces
> to change who is master, the mac is correctly updated each time.
> 
> I also looked into using use_vmac due to this (and because the above
> method takes 9-10 seconds for failover to occur which should be
> faster with vmac), and while my kernel (4.7.8) appears to have a
> version of the required patch I still get an error. 
> 
> Tue Oct 23 10:07:51 2018: Netlink: error: Operation not supported,
> type=(16), seq=1540289275, pid=0
> Tue Oct 23 10:07:51 2018: (vSwitch1_vrrp1): Unable to create VMAC
> interface vrrp.1
> Tue Oct 23 10:07:51 2018: (vSwitch1_vrrp1) entering FAULT state
> 
> 
> --
> Paul