Open ephemeral-m opened 6 months ago
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.
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
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
Configuration file: