Mac address issue.

--===============5304984498783595926==
Content-Type: multipart/alternative; boundary="00000000000046a9fc0578f76c17"

--00000000000046a9fc0578f76c17
Content-Type: text/plain; charset="UTF-8"

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

--00000000000046a9fc0578f76c17
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Testing out keepalived operation as regar=
d 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 s=
ee a gratuitous arp being sent correctly over the network, so that when I p=
ing from a client the mac address of the new master is shown when queried (=
the physical interfaces mac).=C2=A0<div><br></div><div>However if I bring b=
ack 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 add=
ress of the backup physical interface, when the mac should be updated to th=
e new/previous master.=C2=A0</div><div><br></div><div>This is not an issue =
if I am bringing up and down tracked interfaces to change who is master, th=
e mac is correctly updated each time.</div><div><br></div><div>I also looke=
d 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 g=
et an error.=C2=A0</div><div><br></div><div><pre style=3D"margin-top:0px;ma=
rgin-bottom:0px;padding:0px;max-height:30em;overflow:auto;word-wrap:normal;=
word-break:normal;color:rgb(23,43,77);font-size:12px;background-color:rgb(2=
45,245,245)">Tue Oct 23 10:07:51 2018: Netlink: error: Operation not suppor=
ted, type=3D(16), seq=3D1540289275, pid=3D0
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</pre></div>=
<div><br></div><div>--</div><div>Paul</div></div></div>

--00000000000046a9fc0578f76c17--


--===============5304984498783595926==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============5304984498783595926==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

--===============5304984498783595926==--