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.
Created attachment 579598 [details] Allow-duplicate-address-dectection-to-be-disabled.patch
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.
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