Keepalived works pretty well using multicast messages, unless the network infrastructure does not support multicasting, or when you need to run keepalived in a virtualized/containerized environment and need more than 256 instances of it.
The 256 instances of keepalived limitation stems from the virtual_router_id option in the keepalived.conf file, which accept values from 0-255.
So what happens if you have to run more than 256 keepalived pairs on the same network?
There are two options:
- You need to segment the multicast /4 into smaller subnets and specify that in each keepalived.conf
- Get away with multicast completely and use unicast instead.
Starting with release 1.2.8 unicast is supported, and the config file looks like this:
You can check that there's no multicast traffic by running tcpdump:
Two other useful features of keepalived that are not so well documented are the notify and script tracking options:
The vrrp_script option on line 3 specifies what script to run and the following few lines at what duration. The script can be anything as long as it returns 0 on success and > 0 on failure.
When the script returns 1, keepalived will change its state to FAULT, and if it's the current MASTER will drop the VIP and stop sending multicast messages, if multicast is enabled (in this example it is not, as I am using unicast). The next time the script returns 0, the state will change to BACKUP if nopreempt is specified.
The final interesting bit is the notify stanza on line 36, which calls a script after a state change has occurred (e.g. transition from MASTER to BACKUP, or from MASTER to FAULT). As with the vrrp_script this can be any script. Keepalived passes the following 3 parameters to the notify script:
- $1 = “GROUP” or “INSTANCE”
- $2 = name of group or instance
- $3 = target state of transition (“MASTER”, “BACKUP”, “FAULT”)
The example keepalived.state.sh script on line 36 and 55 uses the STATE parameter to log the current state of keepalived.
