1

I'm planning to deploy a several keepalived routers to maintain floating IPs for different database clusters. The plan is to deploy a separate VRRP instance on each cluster locally according to this guide so there will be only two VRRP routers/instances on each cluster.

The keepalived package available from the CentOS 6x repository is 1.2.7 and it seems that unicast wasn’t a part of the main keepalived code base until around version 1.2.8.

Q1. I wonder if multiply VRRP routers can flood the network with multicast advertisement and cause some performance issue? Would you recommend to use unicast in this case? However I've noticed the following warning related to unicast (Ref.):

vrrp: disable TTL sanity check for unicast use-case. In order to protect against any packet injection, VRRP provides sanity check over IP header TTL. This TTL MUST be equal to 255 and means both sender and receiver are attached on the same ethernet segment. Now with unicast extension this protection MUST be disabled since VRRP adverts will mostly traverse different network segments. !!! WARNING !!! When using VRRP in unicast use-case in order to protect against any packet injection the best practice is to use IPSEC-AH auth method otherwise you are exposed to potential attackers !

Q2. Why other servers on the network that are not members of the vrrp.mcast.net mulicast group still receive VRRP advertisement?

# netstat -g
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      all-systems.mcast.net
eth0            1      all-systems.mcast.net
eth1            1      all-systems.mcast.net
lo              1      ff02::1
eth0            1      ff02::1:ff33:2440
eth0            1      ff02::1
eth1            1      ff02::1:ff90:4d5b
eth1            1      ff02::1

-

# tcpdump -i eth1 -c 2 host vrrp.mcast.net
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
20:30:46.241228 IP 172.16.0.70 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 3, prio 1, authtype simple, intvl 1s, length 20
20:30:47.241372 IP 172.16.0.70 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 3, prio 1, authtype simple, intvl 1s, length 20
2 packets captured
2 packets received by filter
0 packets dropped by kernel

I guess another approach would be to deploy only a single pair of VRRP routers and maintain VIPs for all DB clusters.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.