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.
When running clusters configured for "direct routing" as described here:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Load_Balancer_Administration/s1-lvs-direct-VSA.html
we would prefer to be able to add the shared virtual ip address to each member node within /etc/sysconfig/ifcfg-eth(n) scripts via the IPADDR(n) method. This ensures that the VIP is re-added whenever the network scripts are started/stopped, instead of relying on rc.local as the documentation recommends.
The /etc/sysconfig/network-scripts/ifup-eth script contains a check to ensure that the address to be added does not respond to a DAD request on the interface where it will be added. If the VIP is already active on the load balancer for the cluster, this prevents the network scripts from adding the VIP.
Please allow administrators (who have configured arptables or iptables to properly respond to ARP requests for the VIP) the option of disabling this check by setting "ARPCHECK(n)=no" inside the interface's configuration script file.
I've included a patch of what that might look like.
Honestly, I'd be more amenable to removing it entirely, if that wasn't a behavior change in a released product. I'm not sure what purpose it really serves.
I understand its purpose to be the prevention of duplicate addresses on the local segment. It's not unthinkable that a shop (like ours) could mistakenly deploy a clone or misconfigure a config management script to assign a duplicate address.
However, we'd be pleased with the change either way..
Sure, it's not unthinkable that there could be a misconfiguration, but testing for all potential misconfigurations...
(As an example, NetworkManager does not do this check.)
If this were to be configurable, you'd want to also block off the arping neighbor update as well, correct? I wonder if this should just overload and key off the existing ARP variable.
The neighbor update is harmless if arptables has been correctly configured to mangle arp replies leaving the local interface. On the other hand, if arptables hasn't been correctly configured, a neighbor update isn't doing any harm other than making the address immediately conflict on the segment, which is going to happen fairly quickly anyway.
Comment 7RHEL Program Management
2012-05-03 05:31:55 UTC
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.
Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2013-0518.html