Bug 815431 - feature request: deconfigure duplicate address check
Summary: feature request: deconfigure duplicate address check
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.4
Hardware: All
OS: Linux
medium
low
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 782183
TreeView+ depends on / blocked
 
Reported: 2012-04-23 15:25 UTC by bcodding
Modified: 2018-12-01 18:18 UTC (History)
6 users (show)

Fixed In Version: initscripts-9.03.32-1.el6
Doc Type: Enhancement
Doc Text:
Feature: Allow duplicate address detection to be disabled Reason: Let administrator use direct routing without arp check Result (if any):
Clone Of:
Environment:
Last Closed: 2013-02-21 10:25:47 UTC
Target Upstream Version:


Attachments (Terms of Use)
Allow-duplicate-address-dectection-to-be-disabled.patch (84 bytes, text/plain)
2012-04-23 15:26 UTC, bcodding
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0518 normal SHIPPED_LIVE initscripts bug fix and enhancement update 2013-02-20 21:29:01 UTC

Description bcodding 2012-04-23 15:25:34 UTC
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.

Comment 1 bcodding 2012-04-23 15:26:42 UTC
Created attachment 579598 [details]
Allow-duplicate-address-dectection-to-be-disabled.patch

Comment 3 Bill Nottingham 2012-04-24 18:59:56 UTC
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.

Comment 4 bcodding 2012-04-24 19:23:12 UTC
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..

Comment 5 Bill Nottingham 2012-04-24 21:35:17 UTC
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.

Comment 6 bcodding 2012-04-25 00:53:24 UTC
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 7 RHEL Product and 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.

Comment 12 errata-xmlrpc 2013-02-21 10:25:47 UTC
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


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