Re: MAC handling RFC compliant?

Thanks for the info. This was helpful!


Lennart Sorensen wrote:
> 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).
>
>   

-- 
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
[email protected]
541-410-2760
Making computers work for you!

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk

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