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.
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
(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.
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 ***
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