Does keepalived run additional checks when VRRP lost?

[ATX-250]

Hello everyone!

Is it possible to configure keepalived so that a BACKUP server does not immediately take over the virtual IP when it stops receiving VRRP packets — and instead runs an additional script to check if the MASTER is still alive?

Here's my setup:

• Two Linux-based routers connected via a ~20km direct optical L2 link

• Each router has its own independent internet uplink

• R1 handles clients in 10.4.0.0/16 and 192.168.20.0/24

• R2 handles clients in 10.3.0.0/16

The 192.168.20.0/24 subnet is shared and must be available for both sides.

My goal is:

• When the L2 link between R1 and R2 goes down and R2 stops receiving VRRP packets from R1,
• R2 should not immediately become MASTER and claim the virtual IP 192.168.20.1/24.
• Instead, R2 should run a script to ping R1 over the internet and if reachable, establish a VPN tunnel to access 192.168.20.0/24.
• Only if R1 is truly unreachable (e.g., powered off, crashed), then R2 should promote itself to MASTER and take over the VIP.

I know how to implement this entirely with bash scripts and external monitoring, but I’m curious if it can be achieved using just keepalived mechanisms — ideally with track_script, notify_fault, or other native hooks.

Thanks in advance!

[pqarmitage]

The simple answer to you headline question is: No. If a VRRP instance is not receiving adverts, or it is only receiving lower priority adverts and nopreempt, and the VRRP instance is not in fault state, then that VRRP instance will unconditionally become master.

In your scenario described above, one action is:

Instead, R2 should run a script to ping R1 over the internet and if reachable, establish a VPN tunnel to access 192.168.20.0/24.

Does this mean that the tunnel is already configured on R1? If so, then the tunnel may just as well be permanently configured on R2 as well, so far as I can see.

I can see two solutions managed entirely by keepalived:

1. Permanently have a VPN tunnel configured between R1 and R2 that is routed over the internet. These can be configured in scripts configured using startup_script, and removed using shutdown_scripts.
2. Use notify_fifo and notify_fifo_script to save the current state of the VRRP instance (a notify_script could be used, but they are not reliable if there is a rapid double state change (e.g. backup -> master -> backup) to the local file system.
3. Use an unweighted track_script that returns success if the VRRP instance is in master state or pinging the remote system via the tunnel is unsuccessful, and returns failure if the local instance is in backup or fault state and the remote system can be pinged (via the tunnel). This means that if the remote system is reachable then the local instance will be in fault state, and so cannot become master.
4. This means that the local system will only be able to become master if it is not receiving VRRP adverts AND it cannot ping the remote system.

An alternative approach:

1. As above, have a VPN tunnel over the internet between the systems.
2. The VRRP instances will have to be configured to use unicast_src/unicast_peers, such that the VRRP packets will route over the 20km optical link, but without an interface configured.
3. Configure nftables to duplicate the VRRP adverts, and DNAT, so that there are duplicate adverts are sent over the internet VPN.
4. NAT may be needed at the backup end, possibly on both the source and destination addresses, so that the backup VRRP instance recognises the VRRP adverts received via the VPN.
5. This means that every advert will be send via the optical link and the VPN, so if either route is working, R1 will remain master and R2 will remain backup.

Please do let us know how you get on, and provide details on your working solution.

[ATX-250]

Hi pqarmitage!

Thanks a lot for your reply! It's a bit sad that keepalived can't run additional scripts when VRRP packets are lost :(

Anyway, I’ve implemented a different solution now — I have an independent Bash script running outside of keepalived. It checks if R1 is reachable via both internal and external IPs. If the internal IP is unreachable but the external IP responds, the script starts an OpenVPN tunnel and routes 192.168.20.0/24 through it.

If both IPs are unreachable, keepalived will take over the VIP from R1.
R2 uses a track_script with weight = 0, and if R1 responds via its external IP, the script puts R2 into the FAULT state so it won’t take the VIP even if VRRP packets are lost.

I really like your suggestion about having a permanently active VPN tunnel and using unicast peers for VRRP communication. I hadn’t considered that — great idea!