MAC of VIP not updated in VRF in a VRRP scenario

[eon]

Using a simple setup where I have 2 VRRP nodes with keepalived and a client VM on the same subnet that pings the VIP.

The VIP is configured using allow address pairs.

Looking at the VRF of the client machine port I can see that the VIP MAC is not updated when the master VRRP node goes down:

# rt --dump 10 | grep 15.15.15.15/32
15.15.15.15/32 32 LP 40 28 2:81:ca:87:ff:66(11936)
# rt --dump 10 | grep 15.15.15.15/32
15.15.15.15/32 32 LP 40 28 2:81:ca:87:ff:66(11936)
(keepalived stopped on master)
# rt --dump 10 | grep 15.15.15.15/32
15.15.15.15/32 32 LP 29 29 2:81:ca:87:ff:66(11936)
# rt --dump 10 | grep 15.15.15.15/32
15.15.15.15/32 32 LP 29 29 2:81:ca:87:ff:66(11936)

We can see the route change (mpls label and nh updated) but not the MAC.

As a result if an ARP request is made on the VIP by the client it gets the wrong MAC so the connection doesn't work anymore.

Using the noping tool instead of ping should show this behaviour.

[eon (eon-5)]

ICMP and ARP tcpdump capture with ping where you can see the failover working fine. You can see GARP from keepalived but no explicit ARP request to 15.15.15.15 (the VIP). So the ARP table is updated by the VM OS according to the GARP.

[eon (eon-5)]

ICMP and ARP tcpdump capture with noping. You can see after the failover and the GARP from keepalived an ARP request from the client for the VIP and a response with the wrong MAC (the one that is in the VRF and which is not correct)

[eon (eon-5)]

Using R2.21.x

[eon (eon-5)]

The XMMP update sent by the controller when the VIP move is:

<?xml version="1.0"?>
<message <email address hidden>" to="ctl/bgp-peer">
 <event xmlns="http://jabber.org/protocol/pubsub">
  <items node="1/1/default-domain:jpbraun:aap_net:aap_net">
   <item id="15.15.15.15/32">
    <entry>
     <nlri>
      <af>1</af>
      <safi>1</safi>
      <address>15.15.15.15/32</address>
     </nlri>
     <next-hops>
      <next-hop>
       <af>1</af>
       <address>10.35.2.17</address>
       <label>40</label>
       <tunnel-encapsulation-list>
        <tunnel-encapsulation>gre</tunnel-encapsulation>
        <tunnel-encapsulation>udp</tunnel-encapsulation>
       </tunnel-encapsulation-list>
      </next-hop>
     </next-hops>
     <version>1</version>
     <virtual-network>default-domain:jpbraun:aap_net</virtual-network>
     <sequence-number>121</sequence-number>
     <security-group-list>
      <security-group>8000007</security-group>
     </security-group-list>
     <local-preference>200</local-preference>
    </entry>
   </item>
  </items>
 </event>
</message>

This confirms the correct change of the mpls label for the VIP route. But the update doesn't contain the new MAC address.

[Naveen N (naveenn)]

Was the allowed address pair configured with IP + mac combination or just IP?
If it was configured with just IP and no mac then this bug may be a duplicate of #1549339.

[eon (eon-5)]

The AAP was configured with no MAC, so by default the MAC is the same as the VMI in the API server.

It may be more a duplicate of this one: https://bugs.launchpad.net/juniperopenstack/+bug/1533509

[eon (eon-5)]

I guess I didnt have this commit either: https://github.com/Juniper/contrail-controller/commit/fb8d8fdc6a2607477d4e6abdef4e5b0c3c39c3d5

[eon (eon-5)]

Will test with a new build