RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1297445 - dhclient: Unicast requests sent on "wrong" interface
Summary: dhclient: Unicast requests sent on "wrong" interface
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dhcp
Version: 6.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Pavel Šimerda (pavlix)
QA Contact: Release Test Team
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks: 1269194 1356054 1359261
TreeView+ depends on / blocked
 
Reported: 2016-01-11 14:27 UTC by Jiri Popelka
Modified: 2020-01-17 15:38 UTC (History)
7 users (show)

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.
Clone Of: 1177351
Environment:
Last Closed: 2016-11-08 15:08:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.