Support the VRRP synchronization group to take action when any of the grouped instances stops receiving VRRP advertisements

[StrongTux]

Is your feature request to resolve a problem or provide enhanced functionality? Please describe.
Right now, the only way for the VRRP synchronization group to act is when all VRRP instances stop receiving VRRP advertisements. A situation where all VRRP instances are not receiving VRRP advertisements, but one is, results in the VRRP synchronization group to do nothing.

Describe the solution you would like
Allow the possibility to configure the VRRP synchronization group to act if any instance in the group stops receiving VRRP advertisements (OR instead of AND). One way to force a new master election could be to increase the priority of all grouped instances, forcing a new MASTER election.

Describe alternatives you have considered
I've tried to force the VRRP group to act with VRRP scripts (ICMP) and BFD, using weights and priorities, but the result is unreliable

Would the feature request be of benefit only to you, or is it more generally applicable?
It would benefit anyone using a VRRP sync group, anyone interested in forcing a new MASTER election when any of the grouped VRRP instances stops receiving VRRP advertisements

Keepalived version
Keepalived v2.1.5 (07/13,2020)

Copyright(C) 2001-2020 Alexandre Cassen, acassen@gmail.com

Built with kernel headers for Linux 5.10.70
Running on Linux 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30)

configure options: --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --with-kernel-dir=debian/ --enable-snmp --enable-sha1 --enable-snmp-rfcv2 --enable-snmp-rfcv3 --enable-dbus --enable-json --enable-bfd --enable-regex build_alias=x86_64-linux-gnu CFLAGS=-g -O2 -ffile-prefix-map=/build/keepalived-jCUlld/keepalived-2.1.5=. -fstack-protector-strong -Wformat -Werror=format-security LDFLAGS=-Wl,-z,relro CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2

Config options: NFTABLES LVS REGEX VRRP VRRP_AUTH JSON BFD OLD_CHKSUM_COMPAT FIB_ROUTING SNMP_V3_FOR_V2 SNMP_VRRP SNMP_CHECKER SNMP_RFCV2 SNMP_RFCV3 DBUS

System options: PIPE2 SIGNALFD INOTIFY_INIT1 VSYSLOG EPOLL_CREATE1 IPV4_DEVCONF IPV6_ADVANCED_API LIBNL3 RTA_ENCAP
RTA_EXPIRES RTA_NEWDST RTA_PREF FRA_SUPPRESS_PREFIXLEN FRA_SUPPRESS_IFGROUP FRA_TUN_ID RTAX_CC_ALGO RTAX_QUICKACK RTEXT_FILTER_SKIP_STATS FRA_L3MDEV FRA_UID_RANGE RTAX_FASTOPEN_NO_COOKIE RTA_VIA FRA_OIFNAME FRA_PROTOCOL FRA_IP_PROTO FRA_SPORT_RANGE FRA_DPORT_RANGE RTA_TTL_PROPAGATE IFA_FLAGS IP_MULTICAST_ALL LWTUNNEL_ENCAP_MPLS LWTUNNEL_ENCAP_ILA NET_LINUX_IF_H_COLLISION LIBIPVS_NETLINK IPVS_DEST_ATTR_ADDR_FAMILY IPVS_SYNCD_ATTRIBUTES IPVS_64BIT_STATS IPVS_TUN_TYPE IPVS_TUN_CSUM IPVS_TUN_GRE VRRP_VMAC VRRP_IPVLAN IFLA_LINK_NETNSID CN_PROC SOCK_NONBLOCK SOCK_CLOEXEC O_PATH GLOB_BRACE INET6_ADDR_GEN_MODE VRF SO_MARK SCHED_RESET_ON_FORK

Additional context
Two virtual routers, one master and one backup. Two VRRP instances, public and LAN. If the backup router stops receiving VRRP advertisements on the backup or public instances, when not configured with the VRRP synchronization group, it results in both routers being MASTER on either instance, which is undesirable. When configured with the VRRP synchronization group, the backup becomes master when the public and LAN instances stop receiving advertisements, which is also undesirable since failover is only triggered when the MASTER is fully down. The ideal situation would be for backup to take over master role in all VRRP instances when it stops receiving advertisements for any VRRP instance.

[pqarmitage]

I'm not clear what you are asking for here. The current situation is that if ANY member of a sync group cannot be master (either due to being in fault state or there is a higher priority instance currently master or nopreempt is configured and another instance became master first), then none of the members of the sync group will be master. The members of a sync group can only be master if ALL member instances are eligible to become master.

I think you are requesting that if any member of the sync group is eligible to become master, then all members of the sync group become master.

Consider the following configuration:
Machine A

vrrp_sync_group GROUP {
    group {
        VRRP_1
        VRRP_2
    }
}

vrrp_instance VRRP_1 {
    priority 200
    virtual_router_id 10
    ...
}

vrrp_instance VRRP_2 {
    priority 150
    virtual_router_id 20
    ...
}

Machine B

vrrp_sync_group GROUP {
    group {
        VRRP_1
        VRRP_2
    }
}

vrrp_instance VRRP_1 {
    priority 150
    virtual_router_id 10
    ...
}

vrrp_instance VRRP_2 {
    priority 200
    virtual_router_id 20
    ...
}

Both machine A and machine B have a vrrp_instance eligible to become master, and so if the sync group worked by having any instance eligible to be master then all instances become master, then there would be multiple masters for the two VRRP instances.

You suggest a possibility of increasing the priorities of the other instances in the sync group, but both systems would do that and there would still be the same problem. At least the way it works at the moment none of the instances become master and we don't experience a split-brain issue.

It might be possible to add a keyword eligible_master_group_priority_increase n in a vrrp instance (or in the sync group itself), which would mean that for any instance that is eligible to be master the other instances in the group have their priority increased by the amount specified. However, I don't know if this would achieve what you want.

Could you please provide some sample configurations, and explain how you would like it to work. By all means introduce some new configuration keywords (such as eligible_master_group_priority_increase) with an explanation of what they would do, and then we can investigate this further.

[pqarmitage]

Closing due to no response for over 3 weeks.