Trigger GARP after VRRP send failure without state change

[KolozsSandor]

Describe the bug
Keepalived logs the message:
Cant send advert to <peer_ip> (Operation not permitted)
when a unicast VRRP advertisement cannot be sent, for example due to temporary kernel conntrack exhaustion. In this scenario:

• The master remains in the MASTER state.
• Notify scripts (notify_master, notify_backup, notify_fault) do not run, because no state transition occurs.
• Backup node (peer_ip) may briefly promote themselves if they stop receiving advertisements, creating a micro split-brain scenario. Backup sends GARPs out.

Once the original master resumes sending, <peer_ip> goes to BACKUP, but no automatic mechanism exists to stabilize the network and revert to original master (e.g., sending gratuitous ARPs), and many node tries the backup node, as it is in their arp cache for VIP.

To Reproduce
It occurred for me when conntrack was exhausted for a moment:
Add input accept nft rules for vrrp - this causes conn-tracking vrrp packets, decrease conntrack-max and DOS the MASTER node, so keepalived somehow can't send packets because this.

Expected behavior
Detect VRRP send failures (unicast or multicast).
Go to FAILED state (distruptive a bit), or stay in MASTER state but:
Trigger a corrective action without requiring a state transition, such as:

Send gratuitous ARPs (GARP) for all VIPs.
Provide configuration options, for example:
on_send_failure { send_garp 3 alert true }

Keepalived version

Keepalived v2.2.8 (04/04,2023), git commit v2.2.7-154-g292b299e+

Distro (please complete the following information):

• Name: [Ubuntu]
• Version: [Ubuntu 24.04.3 LTS]
• Architecture: [x86_64]

Details of any containerisation or hosted service (e.g. AWS)
None

Configuration file:

Notify and track scripts

none

System Log entries

Confidential, sorry

BR
Sandor

[pqarmitage]

I think a system that cannot create conntrack entries will be in a rather broken state, but nevertheless I agree we should try not to break other systems.

Going to fault state will not work if a send advert fails since there will be no event that keepalived can detect to bring the vrrp instance out of fault state. I think the solution is to transition to backup state; that way the vrrp instance will attempt to become master again after 3 and a bit advert intervals and hence send the desired GARP messages. If the system is still unable to send adverts, then it will revert to backup state again, and there will be no indication outside the system that it has attempted to become master again. There will be a problem though if adverts to some unicast peer(s) are sent successfully before an advert to the next unicast peer fails (e.g. the conntrack table is filled up by the first few adverts, or advert would be sent on a different network interface). An alternative is, if an advert fails, to mark the unicast peer as needing to send GARPs, so that when keepalived can successfully send an advert again to that peer, it also sends GARP messages.

I recollect there have been conntrack related issues before, but I cannot recall what issue number it was. The problem was that a system could not receive VRRP adverts until it had sent an advert since there was no matching conntrack entry until an advert had been sent. This meant that when keepalived started, the VRRP instances would always transition to master, and then, if there were a higher priority instance, transition back to backup state after receiving a higher priority advert.

I cannot see any reason why there needs to be conntrack entries for VRRP adverts, and so possibly the solution is to mark VRRP adverts as notrack in nftables. I will experiment with this to see what I can work out.