Hide Forgot
+++ This bug was initially created as a clone of Bug #1177351 +++ Description of problem: dhclient fails to renew IP addresses from the same subnet on a VM with 2 nics (eth0, eth1) configured for dhcp via network-service. The DHCPDISCOVERY stage works fine and both eth0 and eth1 will get an IP address. But while in renewing state and with similar routes on each interface, eth1 seems to send its DHCPREQUEST through the eth0 interface and renewal for eth1 fails while renewal for eth0 succeeds. How reproducible: Add VM with EL7 and at least 2 nics, disable NetworkManager, enable network-service, configure nics for dhcp in ifcfg-eth{1,2}, configure dhcp server to assign an IP address to both nics from the same subnet, start VM, see initial DHCPDISCOVERY succeed for eth0 and eth1, see all subsequent renewals via DHCPREQUEST fail for eth1 (and still succeed for eth0). Steps to Reproduce: 1. add VM with 2 nics, enable network-service + dhcp, start VM 2. after initially succesfully obtaining 2 leases wait for renewal 3. renewal fails for eth1, succeeds for eth0 Actual results: Renewal fails for eth1 Expected results: Renewal succeeds for eth1 Additional info: The problem was reported several times on the dhcp mailing list but no response from ISC (examples: https://lists.isc.org/pipermail/dhcp-users/2013-February/016398.html and https://lists.isc.org/pipermail/dhcp-users/2014-April/017835.html). A patch to fix this issue by Guillaume Nault is referenced here: https://community.ubnt.com/t5/EdgeMAX/WAN-dropped-DHCP-renew-fixes-it/m-p/783774 --- Additional comment from Patrick Laimbock on 2014-12-30 20:05:08 CET --- The thread on the dhcp-hackers mailinglist where this issue was most recently reported: https://lists.isc.org/pipermail/dhcp-hackers/2014-December/002103.html Nexy to Guillaume's patch, Ben Greear also has a number of patches available at: https://github.com/greearb/dhcp-ct/commits/master
Replying (to previous private comments) in public comment: What the patch does is that when there are more interfaces on same subnet, with the patch the client sends DHCPREQUESTs via correct interface. The thing is that even with the applied patch the server sometimes sends DHCPACKs (replies to client's DHCPREQUESTs) to wrong MAC address and dhclient (listening on other interface) does not see them. What MAC address is the DHCPACK sent to is I think based on ARP reply, which is a kernel mechanism, so nothing we can change - well there should be one way - but only for debugging purposes - 'sysctl net.ipv4.conf.all.arp_filter=1'. Per https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt the default setting (0) of arp_filter means that: "The kernel can respond to arp requests with addresses from other interfaces." and setting to 1 means: "Allows you to have multiple network interfaces on the same subnet ... In other words it allows control of which cards (usually 1) will respond to an arp request." So my conclusion at this moment would be that the problem is not fixed completely, but the missing part is nothing we can change.
Something else that is not optimal is what happens when the DHCP server is not on the local subnet. The system cannot make use of the default route to get to the server because the default route is associated with the other interface. So the system ends up sending an ARP for an IP address that is off network. If the router does not do proxy ARPs the ARP is ignored and the DHCPREQUEST is never sent because there is no way to send it. Eventually, the system gives up trying to reach the previous DHCP server and sends a broadcast which is then handled correctly.
qa_ack Reproduced on RHEL-6.6 x86_64 virtual machine
The configuration with multiple interfaces in the same subnet is non-standard and we currently cannot support dhclient in that configuration and we do not have a patch that would actually fix the issue.