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.
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.
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 !
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.