Re: MAC handling RFC compliant?

On Wed, Jul 24, 2013 at 09:49:51AM -0700, Jon Foster wrote:
> The RFC for VRRP seems to indicate that every VIP should get its own MAC
> address. It doesn't appear that that is the way the keepalived works. It
> appears to use the native MAC address of the NIC for the VIP and creates
> a MAC address for the broadcast address.
> 
> Is this the way its supposed to work? The mechanism to transition the
> VIP to another machine being the ARP broadcast as opposed to one machine
> dropping the MAC and another picking it up?

I know we are running it with with vmac interfaces on linux where each
VIP interface does have its own mac.

I know we have a few patches applies, and I can't remember which ones are
already upstream and which ones we got from the mailing list over time.

For example we have this patch:

diff --git a/keepalived/vrrp/vrrp_vmac.c b/keepalived/vrrp/vrrp_vmac.c
index 7dfb7b1..a4e963d 100644
--- a/keepalived/vrrp/vrrp_vmac.c
+++ b/keepalived/vrrp/vrrp_vmac.c
@@ -60,6 +60,49 @@ netlink_link_setlladdr(vrrp_rt *vrrp)
 
       return status;
 }
+static int
+netlink_link_setmode(vrrp_rt *vrrp)
+{
+       int status = 1;
+       struct {
+               struct nlmsghdr n;
+               struct ifinfomsg ifi;
+               char buf[256];
+       } req;
+       struct rtattr *linkinfo;
+       struct rtattr *data;
+
+       memset(&req, 0, sizeof (req));
+
+       req.n.nlmsg_len = NLMSG_LENGTH(sizeof (struct ifinfomsg));
+       req.n.nlmsg_flags = NLM_F_REQUEST;
+       req.n.nlmsg_type = RTM_NEWLINK;
+       req.ifi.ifi_family = AF_INET;
+       req.ifi.ifi_index = IF_INDEX(vrrp->ifp);
+
+       linkinfo = NLMSG_TAIL(&req.n);
+       addattr_l(&req.n, sizeof(req), IFLA_LINKINFO, NULL, 0);
+       addattr_l(&req.n, sizeof(req), IFLA_INFO_KIND, ll_kind,
+                 strlen(ll_kind));
+
+       data = NLMSG_TAIL(&req.n);
+       addattr_l(&req.n, sizeof(req), IFLA_INFO_DATA, NULL, 0);
+
+       /*
+        * In private mode, macvlan will receive frames with same MAC addr
+        * as configured on the interface.
+        */
+       addattr32(&req.n, sizeof(req), IFLA_MACVLAN_MODE,
+                 MACVLAN_MODE_PRIVATE);
+       data->rta_len = (void *)NLMSG_TAIL(&req.n) - (void *)data;
+
+       linkinfo->rta_len = (void *)NLMSG_TAIL(&req.n) - (void *)linkinfo;
+
+       if (netlink_talk(&nl_cmd, &req.n) < 0)
+               status = -1;
+
+       return status;
+}

 static int
 netlink_link_up(vrrp_rt *vrrp)
@@ -135,6 +178,7 @@ netlink_link_add_vmac(vrrp_rt *vrrp)
       if (new_interface)
               netlink_link_setlladdr(vrrp);
       netlink_link_up(vrrp);
+      netlink_link_setmode(vrrp);

       return 1;
 }

Also it looks like this is in the git tree at least:

commit 1470d553082e04f0d2b24758a359c5c32092cd3d
Author: Alexandre Cassen <[email protected]>
Date:   Wed Jul 11 16:48:47 2012 +0200

    VRRP VMAC fixes:
    
    * Merge patch from Bob Gilligan, <gilligan <at> vyatta.com> : By default
      macvlan interfaces are in VEPA mode, which still filters based on
      source MAC address. VRRP needs to configure its macvlan interfaces
      into private mode to avoid filtering.
    * Merge patch from Bob Gilligan, <gilligan <at> vyatta.com> : extend
      'use_vmac' keyword to support alternate interface definition. By
      default VRRP code use vrrp.{vrid} as interface.
    * Merge patch from Lennart Sorensen, <lsorense <at> csclub.uwaterloo.ca> :
      when using VMAC use primary ip address of the real interface.
    * Create doc/NOTE_vrrp_vmac.txt to clarify and keep track on how to use
      VMAC

So if you use the 'use_vmac' option, then it should behave much better
than if you don't (in which case it assigns the VIP to the normal
interface and hence uses the system mac address, not the virtual mac).

-- 
Len Sorensen

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk