Bug 1297445

Summary:	dhclient: Unicast requests sent on "wrong" interface
Product:	Red Hat Enterprise Linux 6	Reporter:	Jiri Popelka <jpopelka>
Component:	dhcp	Assignee:	Pavel Šimerda (pavlix) <psimerda>
Status:	CLOSED CANTFIX	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	medium	Docs Contact:	Mirek Jahoda <mjahoda>
Priority:	medium
Version:	6.4	CC:	jikortus, jpopelka, ndavids, nparmar, pjanda, praiskup, thozza
Target Milestone:	rc	Keywords:	Patch
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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 15:08:11 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:	1269194, 1356054, 1359261

Description Jiri Popelka 2016-01-11 14:27:58 UTC

+++ 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 19:26:18 UTC

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 20:56:44 UTC

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 13:04:26 UTC

qa_ack Reproduced on RHEL-6.6 x86_64 virtual machine

Comment 20 Pavel Šimerda (pavlix) 2016-11-08 13:34:44 UTC

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.