Keepalived: multicast vs unicast

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.

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?

No sane amount of VRRP routers should cause any issues, even if the advertisements go out every second, it's just one broadcast packet. I would not recommend using unicast because it makes the VRRP setup more brittle than it should be, each time you need to reconfigure the peer IP address you would need to update the configuration of other peers, possibly incurring downtime. Still, I would recommend using IPSEC-AH even in a multicast environment unless you need interoperability with hardware that does not support this type of authentication (keep in mind that PASS authentication is useless from a security standpoint, IPSEC-AH is the only secure authentication type).

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

Multicast traffic that gets into a broadcast domain (L2-adjacent hosts) is broadcasted to all interfaces unless your network hardware is configured to be multicast-aware and respects IGMP requests from your nodes. Often by default, network hardware does not perform IGMP snooping and, hence, just broadcasts all multicast traffic. Given that it's only several packets per second, I would not be worried too much. Adopting an allowlist policy for your firewall would go a long way in helping you isolate unwanted traffic, and VRRP/AH+VRRP/IGMPv3 could be controlled with it.