Bug 1297445 - dhclient: Unicast requests sent on "wrong" interface
dhclient: Unicast requests sent on "wrong" interface
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dhcp (Show other bugs)
6.4
All Linux
medium Severity medium
: rc
: ---
Assigned To: Pavel Šimerda (pavlix)
Release Test Team
Mirek Jahoda
: Patch
Depends On:
Blocks: 1269194 1356054 1359261
  Show dependency treegraph
 
Reported: 2016-01-11 09:27 EST by Jiri Popelka
Modified: 2017-01-04 10:12 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
*DHCP* client sends unicast requests through the incorrect interface *DHCP* client does not support multiple interfaces on the same subnet and it is not able to ensure that unicast requests go through the right interface. Consequently, *DHCP* client fails to renew a lease, and network configuration stops working. There is no known workaround at this point. *DHCP* client cannot be used in configuration with two interfaces connected to the same subnet.
Story Points: ---
Clone Of: 1177351
Environment:
Last Closed: 2016-11-08 10:08:11 EST
Type: Bug
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 Jiri Popelka 2016-01-11 09:27:58 EST
+++ 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
Comment 8 Jiri Popelka 2016-03-01 14:26:18 EST
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.
Comment 9 noah davids 2016-03-01 15:56:44 EST
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.
Comment 16 Petr Janda 2016-10-18 09:04:26 EDT
qa_ack Reproduced on RHEL-6.6 x86_64 virtual machine
Comment 20 Pavel Šimerda (pavlix) 2016-11-08 08:34:44 EST
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.

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