Bug 815431

Summary:

feature request: deconfigure duplicate address check

Product:

Red Hat Enterprise Linux 6

Reporter:

bcodding

Component:

initscripts

Assignee:

Lukáš Nykrýn <lnykryn>

Status:

CLOSED ERRATA

QA Contact:

qe-baseos-daemons

Severity:

low

Docs Contact:

Priority:

medium

Version:

6.4

CC:

azelinka, jscotka, notting, ovasik, syeghiay, vpavlin

Target Milestone:

Keywords:

FutureFeature

Target Release:

---

Hardware:

All

OS:

Linux

Whiteboard:

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):

Story Points:

---

Clone Of:

Environment:

Last Closed:

2013-02-21 10:25:47 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Bug Depends On:

Bug Blocks:

782183

Attachments:

Description	Flags
Allow-duplicate-address-dectection-to-be-disabled.patch	none

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 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