Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem: If keepalived is stopped uncleanly, it is possible for a VIP to be left on a node that shouldn't have it. Even after keepalived is restarted, the improper VIP is not cleaned up.
This was originally reported in https://bugzilla.redhat.com/show_bug.cgi?id=1931505 but as we are working around it in OpenShift I wanted a separate report open against keepalived itself.
Version-Release number of selected component (if applicable): 2.0.10
How reproducible: Always
Steps to Reproduce:
1. Run keepalived with a configuration such as:
vrrp_instance ostest_API {
state BACKUP
interface eth0
virtual_router_id 14
priority 70
advert_int 1
nopreempt
unicast_src_ip 12.1.1.122
unicast_peer {
12.1.1.111
}
authentication {
auth_type PASS
auth_pass ostest_api_vip
}
virtual_ipaddress {
12.2.2.2/32
}
}
2. On the node holding the VIP, run "killall -9 keepalived".
3. Restart keepalived on the node where it was killed.
Actual results: The VIP fails over to another node, but also remains on the one where keepalived was killed.
Expected results: The VIP should be removed from the node where keepalived was killed at some point in the process, either immediately after it is killed or when it restarts.
Additional info: This behavior does not reproduce on Fedora 33 with keepalived 2.1.5. It correctly unconfigures the VIP when keepalived is killed. This is triggered in our product by a failing liveness probe removing the keepalived container, but as noted above I have also reproduced it outside of containers in a VM environment.
(In reply to Ben Nemec from comment #0)
[snip]
> Additional info: This behavior does not reproduce on Fedora 33 with
> keepalived 2.1.5. It correctly unconfigures the VIP when keepalived is
> killed. This is triggered in our product by a failing liveness probe
> removing the keepalived container, but as noted above I have also reproduced
> it outside of containers in a VM environment.
So did you try keepalived-2.1.5 in RHEL8.4?