Re: VRRP and dual-stack

On 15/11/2016 00:58, Quentin Armitage wrote:
> On Mon, 2016-11-14 at 16:54 +0100, Damien Clabaut wrote:
>> Hello,
>>
>> I am trying to setup VRRP on dual-stack (IPv4 + IPv6 on the same vlan).
>>
>> I am using Keepalived 1.2.23 on debian 7.11 (kernel 3.18.11).
>>
>> To be compatible with Cisco devices (which I do not use in this specific
>> case but will use in production), I use VRRPv2 for IPv4 and VRRPv3 for
>> IPv6. Thus, my configuration looks like this:
>>
>> global_defs {
>> }
>>
>> vrrp_instance 61100 {
>>     version 3
>>     native_ipv6
>>     state BACKUP
>>     interface bond0.1100
>>     use_vmac vrrp.35100.1
>>     virtual_router_id 1
>>     priority 150
>>     advert_int 1
>>     virtual_ipaddress {
>>         fe80:b100::1/64
>>         2001:41d0:b100::1/128
>>     }   
>> }
>> vrrp_instance 41100 {
>>     interface bond0.1100
>>     use_vmac vrrp.35100.1
>>     virtual_router_id 1
>>     priority 100
>>     advert_int 1
>>     authentication {
>>         auth_type PASS
>>         auth_pass kpl35100
>>     }
>>     virtual_ipaddress {
>>         10.242.100.254/32
>>     }
>>     mcast_src_ip 10.242.100.254
>>     unicast_src_ip 10.242.100.254
>>    
>> }
>>
>> Configuration is identical on peer router except the priorities are
>> opposite (100 for IPv6 and 150 for IPv4).
>>
>> The machine named bz-perflab-5-vr is master on IPv6, bz-perflab-2-vr is
>> master on IPv4.
>>
>> When loading / reloading the configuration, I get these logs:
>> Nov 14 16:39:25 bz-perflab-5-vr Keepalived_vrrp[10024]:
>> VRRP_Instance(61100) Transition to MASTER STATE
>> Nov 14 16:39:26 bz-perflab-5-vr Keepalived_vrrp[10024]:
>> VRRP_Instance(61100) Entering MASTER STATE
>> Nov 14 16:39:26 bz-perflab-5-vr Keepalived_vrrp[10024]:
>> VRRP_Instance(61100) using locally configured advertisement interval
>> (1000 milli-sec)
>> Nov 14 16:39:26 bz-perflab-5-vr Keepalived_vrrp[10024]: Netlink: error:
>> Permission denied, type=(20), seq=1479137970, pid=0
>> Nov 14 16:39:26 bz-perflab-5-vr Keepalived_vrrp[10024]:
>> 2001:41d0:b100::1 has a prefix length of 128, setting preferred_lft to 0
>> Nov 14 16:39:26 bz-perflab-5-vr Keepalived_vrrp[10024]: Netlink: error:
>> Permission denied, type=(20), seq=1479137971, pid=0
>>
>> In which case bz-perflab-2-vr gets the VIPv4 but none of the routers get
>> the VIPv6.
>> Each router also gets its link-local address (same as underlying VLAN
>> interface bond0.1100).
>>
>> If I reload keepalived again on bz-perflab-5-vr, then I get the same
>> logs, and all IP addresses are removed from the VRRP interface (even
>> link-local). And bz-perflab-2-vr gets both the VIPv4 and the VIPv6.
>>
>> Is this a known issue ? Am I doing anything wrong ?
>>
> Hi Damien,
>
> I think the problem is that you have specified the same VMAC name for
> both the IPv4 and IPv6 VRRP instances. This cannot work, since the
> IPv4 MAC address for the VMAC interface is 00:00:5e:00:01:01, and for
> the IPv6 instance, the MAC address is 00:00:5e:00:02:01, and so these
> must be different VMAC interfaces. Each VMAC interface must have a
> different name due to them either having different MAC addresses, or
> having different underlying interfaces.
>
> To resolve this, you could change the VMAC name in the use_vmac
> statement in vrrp_instance 61100 to be vrrp6.35100.1 for example.
>
> I hope that helps,
> Quentin Armitage 
Hello Quentin,

Thank you very much, it solved the issue.

-- 
Damien Clabaut
Network Engineer
OVH.pl

------------------------------------------------------------------------------

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJYKstIAAoJEH4l99mSZky/Ua8QALoUTg7D6aIoZv2V11djgmNs
w8ej/lPSfq3eJZV7vpD/LcYAGkcVvlQG80LAf2XbPbph1l0/KIaNUNTez4LsTdFC
puKnQnWfyOwzs1N0gFEaLj07SH0ws2Pp90kcFFyP8xAc76i2IwSESS9v1LzJFNQ6
LgbG+0tEFMY6qncKzz9cqich6CXs5H9zRaFq2EpxVKmsVuC2zhhFHZhYGXtpaQ4j
lcore8ujPbzP4XEyGaPdMhfjlDSVxvz2MJ5T9NtkN57p6RKqjs1PBFz9wTM4mRe0
gw9Wy/72xyLuBLOZwRmDAOgl9VAbFe4MT121oDsDCQJ5yh5k0PFMAmcpdr/yOkiM
oHvCf164pWFBZiY2zqEomz1e+ALQPrZzkWz2VFh2+5O/yG61Fzs/Fb12WHb4sr1q
lZsV8lqpcPZMbbQGvMxnoLe7VVVWw4OI0ZogxUY951BwIC/SYUg4cOiZB6x69oA9
X7mODeLNqti7b2lAwilVIyqwsTdJHWcSol2+uwx9pGp2TTbGprm+L5RCebjcP5PV
ZWvcBDWEvHtxxNyIxWikH7u9i3L19TPMNG6/MzieR14dJjywGz949sp10YqIqlwT
CZp2Q2pRUhvo8q8k7daMNRwJ14ELWbetidfuBxlePptBFlw2QgMtF2/sf4N2Je50
GkQcjtyG4LqdtGvOpIKF
=c6Ai
-----END PGP SIGNATURE-----