Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1177351

Summary: dhclient: Unicast requests sent on "wrong" interface
Product: Red Hat Enterprise Linux 7 Reporter: Patrick Laimbock <patrick>
Component: dhcpAssignee: Jiri Popelka <jpopelka>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: fdeutsch, gklein, ljozsa, mkovarik, pbokoc, pjanda, thozza
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: dhcp-4.2.5-38.el7 Doc Type: Bug Fix
Doc Text:
Previously, when using the "dhclient" DHCP protocol client on a host with two network interfaces connected to the same subnet, "DHCPREQUEST" packets were only being sent to one of the interfaces. Consequently, the IP address lease of the other interface was not being renewed. With this update, "dhclient" sends "DHCPREQUEST" and "DHCPRELEASE" packets to both interfaces, even if they are on the same subnetwork.
Story Points: ---
Clone Of:
: 1297445 (view as bug list) Environment:
Last Closed: 2015-11-19 08:56:04 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: 1035038, 1082754, 1112660    
Attachments:
Description Flags
Patch to dhclient: Unicast requests sent on "wrong" interface
none
send unicast request/release via correct interface none

Description Patrick Laimbock 2014-12-26 13:26:43 UTC
Created attachment 973198 [details]
Patch to dhclient: Unicast requests sent on "wrong" interface

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.

Version-Release number of selected component (if applicable):
CentOS 7 (up-to-date)
dhcp-4.2.5-27.el7.centos.2

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

I contacted Guillaume, received the latest version of his patch and rebased it on the 4.2.5 release, added it as the latest patch in the dhcp spec file, rebuilt it, tested the new dhclient on current CentOS 7 and renewal now also succeeds for eth1.

Please let me know if you need more information.

Comment 2 Patrick Laimbock 2014-12-30 19:05:08 UTC
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

Best wishes for 2015.

Comment 3 Jiri Popelka 2015-02-02 17:52:43 UTC
*** Bug 1186727 has been marked as a duplicate of this bug. ***

Comment 4 Jiri Popelka 2015-02-03 11:51:30 UTC
Created attachment 987511 [details]
send unicast request/release via correct interface

Slightly amended
https://community.ubnt.com/ubnt/attachments/ubnt/EdgeMAX/29126/1/bind_fb_iface_4.2.4-P2_1.patch

Comment 8 Michal Kovarik 2015-09-08 11:52:41 UTC
Reproduced with dhclient-4.2.5-36.el7. Verified on dhcp-4.2.5-40.el7. Renewal succeeds for second NIC immediately.

Comment 10 errata-xmlrpc 2015-11-19 08:56:04 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2015-2251.html