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