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 1186727 - IP address is getting lost for a while when having 2 NICs on the same subnet and running dhclient on both
Summary: IP address is getting lost for a while when having 2 NICs on the same subnet ...
Keywords:
Status: CLOSED DUPLICATE of bug 1177351
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dhcp
Version: 7.1
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jiri Popelka
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 1112660
TreeView+ depends on / blocked
 
Reported: 2015-01-28 12:15 UTC by Ladislav Jozsa
Modified: 2015-02-02 17:52 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-02 17:52:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
journalctl output (13.54 KB, text/plain)
2015-01-28 12:15 UTC, Ladislav Jozsa 		no flags Details
journalctl output (95.59 KB, text/plain)
2015-01-28 13:08 UTC, Ladislav Jozsa 		no flags Details
Show Obsolete (1) View All

Description Ladislav Jozsa 2015-01-28 12:15:31 UTC 
Created attachment 985111 [details]
journalctl output

Description of problem:
Both interfaces are on the same subnet. After running ifup ens3 and ifup ens8,  waiting for duration of the lease time, the interface that was brought up later loses its address for a while. It then starts to broadcast request for a new address which is obtained afterwards. See attached output from journalctl -b.

Version-Release number of selected component (if applicable):
# rpm -qa | grep dhc
dhcp-libs-4.2.5-35.el7.x86_64
dhclient-4.2.5-35.el7.x86_64
dhcp-common-4.2.5-35.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. Disable NetworkManager
2. ifup ens3
3. ifup ens8
4. watch ip a a

Actual results:
IP address is lost on the interface that was brought up later

Expected results:
IP address should persist on both interfaces

Additional info:
# systemctl status NetworkManager
NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; disabled)
   Active: inactive (dead)

Config files for interfaces:

# cat /etc/sysconfig/network-scripts/ifcfg-ens3 
HWADDR=52:54:00:1D:28:EC
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=ens3
UUID=a21da164-71b9-496f-9d07-d785cac8ba61
ONBOOT=no

# cat /etc/sysconfig/network-scripts/ifcfg-ens8
HWADDR=52:54:00:0C:C7:EE
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=ens8
UUID=8e3c2c82-e7cc-4ab6-924f-7d9fa065ebd9
ONBOOT=no
Comment 2 Ladislav Jozsa 2015-01-28 13:08:51 UTC 
Created attachment 985142 [details]
journalctl output
Comment 3 Jiri Popelka 2015-01-30 15:32:56 UTC 
(In reply to Ladislav Jozsa from comment #0)
> Both interfaces are on the same subnet. After running ifup ens3 and ifup
> ens8,  waiting for duration of the lease time, the interface that was
> brought up later loses its address for a while. It then starts to broadcast
> request for a new address which is obtained afterwards.

I can reproduce it. It's not caused by bug #1116004 fix, the fix just revealed it.

So far I don't quite understand what's happening but it looks like the second dhclient (on ens8 interface in this case) wrongly fills in source IP & MAC addresses of the REQUEST packets.
It puts there adresses of the first interface (ens3) and the server then seems to send ACK to the first dhclient, so the second one doesn't see them and keeps sending REQUESTs until the lease expires.
Then it restarts the process and gets a new (the same) address.
Comment 4 Jiri Popelka 2015-01-30 16:56:20 UTC 
Tried with latest upstream version and neither of the two running dhclients is able to renew the address.
Comment 5 Jiri Popelka 2015-02-02 17:52:43 UTC 
So I've been investigating this almost whole day, then trying to google out if someone already hit this and what I found is bug #1177351 - shame on me !

*** This bug has been marked as a duplicate of bug 1177351 ***
Note You need to log in before you can comment on or make changes to this bug.