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.
Bug 1110363 - Keepalived on base repository have a serious bug
Summary: Keepalived on base repository have a serious bug
Keywords:
Status: CLOSED DUPLICATE of bug 1077201
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: keepalived
Version: 6.5
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Ryan O'Hara
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-17 13:47 UTC by roxyrob
Modified: 2014-06-17 15:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-17 15:48:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Keepalived nodes /var/log/messages with comment (2.99 KB, application/octet-stream)
2014-06-17 13:47 UTC, roxyrob
no flags Details


Links
System ID Private Priority Status Summary Last Updated
CentOS 0007184 0 None None None Never

Description roxyrob 2014-06-17 13:47:49 UTC
Created attachment 909587 [details]
Keepalived nodes /var/log/messages with comment

Description of problem:
We have a serious problem with Keepalived distributed on red-hat/CentOS base repository.

We installed and configured Keepalived on 2 HA firewalls Virtual Machines (VMWare ESXi infrastructure). Suddenly, Keepalived BACKUP instance (secondary), probably for a little unresponsiveness of network connection, go in "Transition to MASTER STATE", immediately see MASTER (Received higher prio advert) and goes to Backup state "Entering BACKUP STATE". During this sudden transition, VIP remain only on the MASTER but communications on networks managed by MASTER are lost. No communications take place until we restart Keepalived service on the MASTER. Restarting service manually works fine but surviving to this very little BACKUP fluctuation does not work. Also arp advertising does not work correctly on virtualized environment for this Keepalived version (keepalived developers have released many fix for these problems).

At least, on Keepalived site, there is a Change Log similar to the first problem: 2014-01-03 Release 1.2.10 "vrrp: fix/extend gratuitous ARP handling... In some cases those virtualized env offer a virtualized layer2...". Other Change Log with various fix for gratuitous arp behavior.

Can you upgrade keepalived on base repo as we benefit from these fix without manual compiling, breaking future repo meneged upgrades ?
Thank you very much


Version-Release number of selected component (if applicable):
We use RedHat/CentOS 6.5 with Keepalived v1.2.7 (02/21,2013) installed from base repository.


How reproducible:
First issue normally can happen also without specific action, probably due to virtualization mode of network behavior. If you need, you can reproduce this problem making 2 virtual machine with Keepalived in BACKUP-BACKUP with no-preempt configuration. Take a vm snapshot. Little unresponsiveness of a machine reveal this issue (snapshot can be an example, but probably also little network communication interruption between 2 Keepalived nodes).

Second issue is simple. ON virtualization environment (we use VMWare vSphere ESXi 5.5), gratuitous arp does not work correctly, we added a garp command to correct this behavior (keepalived work on layer2).

Steps to Reproduce:
First issue
1. Make 2 Virtual Machine with Keeaplived (BACKUP-BACKUP with no-preempt)
2. Induce a little network interruption between nodes

Second issue
1. Make 2 Virtual Machine with Keeaplived (BACKUP-BACKUP with no-preempt)
2. manually restart service on active node (service keepalived restart)


Actual results:
Firs issue
You can see non-complete transition in /var/log/messages of each node. The Active node is not passing packet for some hosts on connected networks for owned VIPs as soon as you manually restart keepalived after which all works again.

Second issue
The Active node is not passing packet for some hosts on connected networks for owned VIPs. You have to add garp command on keepalived notifications scripts.

Expected results:
Keepalived must automatically manage gratuitous arp and short network problems or short split brain or node unresponsiveness returning to normal situation

Additional info:

Comment 2 Ryan O'Hara 2014-06-17 15:48:48 UTC

*** This bug has been marked as a duplicate of bug 1077201 ***


Note You need to log in before you can comment on or make changes to this bug.