Swap virtual_router_id of two vrrp instance(same interface) cause vip loss when reload

[ephemeral-m]

Describe
Swap virtual_router_id of two vrrp instance(same interface) cause vip loss

To Reproduce
Swap virtual_router_id of two vrrp instance(same interface) , and do keepalived reload(not restart)

Expected behavior
vip will not loss

Keepalived version

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

Copyright(C) 2001-2023 Alexandre Cassen, <acassen@gmail.com>

Built with kernel headers for Linux 5.15.131
Running on Linux 6.2.0-37-generic #38~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov  2 18:01:13 UTC 2
Distro: Ubuntu 22.04.2 LTS

configure options: --prefix=/usr/local/keepalived

Config options:  LVS VRRP VRRP_AUTH VRRP_VMAC OLD_CHKSUM_COMPAT INIT=systemd

System options:  VSYSLOG MEMFD_CREATE IPV6_MULTICAST_ALL IPV4_DEVCONF 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_PROTOCOL FRA_IP_PROTO FRA_SPORT_RANGE FRA_DPORT_RANGE RTA_TTL_PROPAGATE IFA_FLAGS LWTUNNEL_ENCAP_MPLS LWTUNNEL_ENCAP_ILA NET_LINUX_IF_H_COLLISION LIBIPTC_LINUX_NET_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_IPVLAN IFLA_LINK_NETNSID GLOB_BRACE GLOB_ALTDIRFUNC INET6_ADDR_GEN_MODE VRF SO_MARK
```


**Configuration file:**
```
vrrp_instance VI_2 {
    state MASTER
    interface ens33
    virtual_router_id 3
    priority 100
    advert_int 1
    virtual_ipaddress {
        191.168.18.131
    }
}

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 2
    priority 100
    advert_int 1
    virtual_ipaddress {
        192.168.18.130
    }
}
```

[pqarmitage]

This is interesting, and challenging.

Swapping the VRIDs in the vrrp_instances causes the VIP from the second VRRP instance to be lost.

If instead the VIPs are swapped between the vrrp instances (which essentially results in the same configuration except that the vrrp_instance names are swapped compared to just swapping the VRIDs), then no VIP is lost.

The only way I can think of resolving this would be before removing a VIP on reload, check all the other vrrp instances in the new config to see if the VIP should remain set. I think the converse would also need to be done, i.e. to ensure before adding a VIP it is not already set.

I would be grateful if you could describe the use case for the scenario you have described above, since I cannot see a reason for wanting to do this.

[ephemeral-m]

I developed the configuration manager to convert the user configuration to the keepalived configuration. For example, if the user configs 10.10.10.10, 10.10.10.11, 10.10.10.12, the configuration manager will generate something like this:

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 1
    priority 100
    advert_int 1
    virtual_ipaddress {
        10.10.10.10
    }
}
vrrp_instance VI_2 {
    state MASTER
    interface ens33
    virtual_router_id 2
    priority 100
    advert_int 1
    virtual_ipaddress {
        10.10.10.11
    }
}
vrrp_instance VI_3 {
    state MASTER
    interface ens33
    virtual_router_id 3
    priority 100
    advert_int 1
    virtual_ipaddress {
        10.10.10.12
    }
}

But if the user deletes the 10.10.10.10 configuration, the content generated by the configuration manager will look like this:

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 1
    priority 100
    advert_int 1
    virtual_ipaddress {
        10.10.10.11
    }
}
vrrp_instance VI_2 {
    state MASTER
    interface ens33
    virtual_router_id 2
    priority 100
    advert_int 1
    virtual_ipaddress {
        10.10.10.12
    }
}

For 10.10.10.11 and 10.10.10.12, the scenario described in the problem will be triggered and a vip will be lost.

To avoid the above problem, I adjust the logic of the configuration manager. That is, each time the configuration manager generates a new configuration, it is compared with the last keepalived configuration. If this scenario exists, I run the restart keepalived command to ensure that the configuration loads normally