Bug 127232 - DHCPD creates duplicate ARP entries on multiple interfaces.
DHCPD creates duplicate ARP entries on multiple interfaces.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: dhcp (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-04 20:20 EDT by Nathan Tallack
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-03 14:33:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nathan Tallack 2004-07-04 20:20:57 EDT
Description of problem:
When DHCPD is running on a box with dual NIC's, and thus serving both 
interfaces, it is creating duplicate ARP entries for new clients as 
it hands out IP addresses.

So even though it is hearing and respond to the DHCP request on eht0, 
when it makes an entry in the ARP table for the new client's MAC and 
IP, it is makign two entries, one on eth0 and one and eth1.

Eventually the one on the incorrect interface will expire.

The specific problem this is posing for me is when I have eth0 and 
eth1 configured as /25's of the same C Class, the duplicate entries 
result in unroutable communicate attempts to the new client.

That is, while the ARP entry exists for the /25 client as duplicate 
entries, one on each interface, I can not ping that client from the 
DHCP server, or any other host on either two subnets.

However, if I configure my interfaces to be using seperate /24 C 
Class subnets, I can still reach the DHCP client IP address when it 
is assigned, even though duplicate ARP entries exist for a short 
period of time.

So, I am unable to determine if DHCPD creating duplicate ARP entries, 
one for each interface, is an intended artifact of its operation, and 
overlooked because if you are using /24's on each interface, it does 
not result in any connectivity problems.

If this is the case, then there is a problem with this artifact if 
the two interfaces are configured using /25's on each interface from 
the same C Class.

The option of waiting for the duplicate ARP entry to expire is not 
available to me as I am PXE booting, and the short period of 
connectivity problem before the dupliate ARP entry expires prevents 
PXE booting from succeeding.


Version-Release number of selected component (if applicable):


How reproducible:
Every time.

Steps to Reproduce:
1. Configure dual NIC's with /25 space each in single C Class.
2. Configure IP forwarding.
3. Configure DHCPD to operate on both subnets.
4. Use DHCP client on one subnet to request IP from DHCPD.
5. Observe duplicate ARP entries when DHCPD assigns address to new 
client.
6. Observe loss of connectivity to client IP from DHCPD server, or 
any other host on either subnet.

Alternative.
1. Configure dual NIC's with /24 space each with seperate C Classes.
2. Configure IP forwarding.
3. Configure DHCPD to operate on both subnets.
4. Use DHCP client on one subnet to request IP from DHCPD.
5. Observe duplicate ARP entries when DHCPD assigns address to new 
client.
6. Observe no loss of connectivity to client IP from DHCPD server, or 
any other host on either subnet.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jason Vas Dias 2004-08-03 14:33:33 EDT
This problem would appear to be fixed with dhcp-3.0.1-4 in FC3 /
rawhide ( soon to be RHEL 4 ) - or I cannot reproduce it on this
platform.

Here is how I tried to reproduce it :

1. I configure 2 interfaces on the same class C subnet 
   but on different /25 subnets:

   in /etc/sysconfig/network-scripts :
$ more ifcfg-eth[01]
::::::::::::::
ifcfg-eth0
::::::::::::::
# Lite-On|LNE100TX
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
HWADDR=00:A0:CC:28:76:91
IPADDR=192.168.2.129
NETMASK=255.255.255.128
::::::::::::::
ifcfg-eth1
::::::::::::::
# Lite-On|LNE100TX [Linksys EtherFast 10/100]
DEVICE=eth1
ONBOOT=no
BOOTPROTO=none
HWADDR=00:A0:CC:34:CD:26
IPADDR=192.168.2.1
NETMASK=255.255.255.128

Each interface was connected to its own separate hub.

2. I created an absolute minimal dhcpd.conf to serve
   two machines, each connected only to one interface
   on the server through the hubs:
::::::::::::::
/etc/dhcpd.conf
::::::::::::::
ddns-update-style ad-hoc;

subnet 192.168.2.128 netmask 255.255.255.128 {
        option routers 192.168.2.129;
        host dhcp128-1 {
                hardware ethernet 00:D0:59:CF:1A:3D;
                fixed-address 192.168.2.130;
        }
}

subnet 192.168.2.0 netmask 255.255.255.128 {
        option routers 192.168.2.1;
        host dhcp0-1 {
                hardware ethernet 00:30:65:4C:46:C0;
                fixed-address 192.168.2.2;
        }
}

3. I do a 'service dhcpd start', and both machines 
   are granted leases - the arp table now looks like this:
? (192.168.2.2) at 00:30:65:4C:46:C0 [ether] on eth1
? (192.168.2.130) at 00:D0:59:CF:1A:3D [ether] on eth0

   Both machines can 'ping' each other and the server.
  
So, for the latest dhcp release, I am closing this bug. 

If the bug reporter believes anything here indicates a fundamental
difference from their setup, please let me know and I'll re-open &
reinvestigate - please attach ifcfg files and dhcpd.conf.


Comment 2 John Flanagan 2004-12-21 14:41:53 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-566.html

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