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.
Bridge devices no longer fail to obtain an IP address
Previously, bridge devices sometimes failed to obtain an IP address from the DHCP server immediately after system startup. This was caused by a race condition where the "ifup-eth" script did not wait for the Spanning Tree Protocol (STP) to complete its startup. This bug has been fixed by adding a delay that causes "ifup-eth" to wait long enough for STP to finish starting.
DescriptionRichard D Alloway
2016-09-29 18:49:50 UTC
Duplicating the bugs.centos.org ticket here:
Description of problem:
2 Ethernet devices are configured in a team (activebackup) and a network bridge is connected to the team device.
After a reboot (NetworkManager.service is masked) the network.service reports that the team device is up , but there is no link for the bridge. After "systemctl restart network" the bridge receives it's IP.
When the bridge is set to static ip - it always works.
Version-Release number of selected component (if applicable):
initscripts-9.49.30-1.3
How reproducible:
Always
Steps to Reproduce:
1. Contents of /etc/sysconfig/network-scripts/ifcfg-team0-eth1
NAME=team0-eth1
DEVICE=eth1
ONBOOT=yes
TEAM_MASTER=nm-team
DEVICETYPE=TeamPort
2. Contents of /etc/sysconfig/network-scripts/ifcfg-team0-eth2
NAME=team0-eth2
DEVICE=eth2
ONBOOT=yes
TEAM_MASTER=nm-team
DEVICETYPE=TeamPort
3. Contents of /etc/sysconfig/network-scripts/ifcfg-team0
DEVICE=nm-team
TEAM_CONFIG="{\"runner\":{\"name\":\"activebackup\"}}"
DEVICETYPE=Team
NAME=team0
ONBOOT=yes
BRIDGE=nm-bridge
4. Contents of /etc/sysconfig/network-scripts/ifcfg-bridge
DEVICE=nm-bridge
STP=yes
BRIDGING_OPTS=priority=32768
TYPE=Bridge
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=br0
ONBOOT=yes
5. systemctl mask NetworkManager.service
6. Reboot system
7. 'journalctl -xe' contains:
Jul 06 13:00:41 server1.example.com network[996]: Bringing up interface br0:
Jul 06 13:00:48 server1.example.com network[996]: Determining IP information for nm-bridge... failed; no link present. Check cable?
Jul 06 13:00:48 server1.example.com network[996]: [FAILED]
Jul 06 13:00:48 server1.example.com systemd[1]: network.service: control process exited, code=exited status=1
Jul 06 13:00:48 server1.example.com systemd[1]: Failed to start LSB: Bring up/down networking.
Jul 06 13:00:48 server1.example.com systemd[1]: Unit network.service entered failed state.
Jul 06 13:00:48 server1.example.com systemd[1]: network.service failed.
8. systemctl restart network
9. 'journalctl -xe' now contains:
Jul 06 13:06:57 server1.example.com network[2796]: Bringing up interface br0:
Jul 06 13:06:57 server1.example.com dhclient[3251]: DHCPREQUEST on nm-bridge to 255.255.255.255 port 67 (xid=0x3c9dd4c3)
Jul 06 13:06:57 server1.example.com dhclient[3251]: DHCPACK from 192.168.100.1 (xid=0x3c9dd4c3)
Jul 06 13:07:00 server1.example.com network[2796]: Determining IP information for nm-bridge... done.
Jul 06 13:07:01 server1.example.com network[2796]: [ OK ]
Actual results:
Bridge interface cannot get a DHCP assigned IP during boot. Restarting network allows bridge interface to get a DHCP assigned IP.
Expected results:
Bridge interface should get a DHCP assigned IP during boot.
Additional info:
Comment 1Richard D Alloway
2016-09-29 18:50:50 UTC
I was able to replicate this issue and have resolved it with a patch that I will attach momentarily.
The issue was that, if DELAY is not set in ifcfg-br0, the init script would not wait for STP to complete startup before attempting to obtain an IP via DHCP.
DELAY is now set by obtaining the forward_delay directly from the interface if DELAY is not otherwise defined.
Let me know if you have any questions or concerns about this patch.
-Rich Alloway (RogueWave)
Comment 2Richard D Alloway
2016-09-29 18:52:40 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://access.redhat.com/errata/RHBA-2018:0983
Comment 12zeloaipi
2023-06-22 01:39:43 UTC
Comment hidden (spam)
The issue of a bridge device failing to obtain an IP address from DHCP when connected to a teamed device without an available link, but functioning properly after a network restart, is a common and frustrating problem. This situation occurs when the bridge device is unable to establish a connection with the DHCP server due to the absence of a valid network link.
https://2048cupcakes.io/
Comment 13Lynn Davenport
2023-09-25 08:29:41 UTC
Comment hidden (spam)
This comment was flagged a spam, view the edit history to see the original text if required.
Duplicating the bugs.centos.org ticket here: Description of problem: 2 Ethernet devices are configured in a team (activebackup) and a network bridge is connected to the team device. After a reboot (NetworkManager.service is masked) the network.service reports that the team device is up , but there is no link for the bridge. After "systemctl restart network" the bridge receives it's IP. When the bridge is set to static ip - it always works. Version-Release number of selected component (if applicable): initscripts-9.49.30-1.3 How reproducible: Always Steps to Reproduce: 1. Contents of /etc/sysconfig/network-scripts/ifcfg-team0-eth1 NAME=team0-eth1 DEVICE=eth1 ONBOOT=yes TEAM_MASTER=nm-team DEVICETYPE=TeamPort 2. Contents of /etc/sysconfig/network-scripts/ifcfg-team0-eth2 NAME=team0-eth2 DEVICE=eth2 ONBOOT=yes TEAM_MASTER=nm-team DEVICETYPE=TeamPort 3. Contents of /etc/sysconfig/network-scripts/ifcfg-team0 DEVICE=nm-team TEAM_CONFIG="{\"runner\":{\"name\":\"activebackup\"}}" DEVICETYPE=Team NAME=team0 ONBOOT=yes BRIDGE=nm-bridge 4. Contents of /etc/sysconfig/network-scripts/ifcfg-bridge DEVICE=nm-bridge STP=yes BRIDGING_OPTS=priority=32768 TYPE=Bridge 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=br0 ONBOOT=yes 5. systemctl mask NetworkManager.service 6. Reboot system 7. 'journalctl -xe' contains: Jul 06 13:00:41 server1.example.com network[996]: Bringing up interface br0: Jul 06 13:00:48 server1.example.com network[996]: Determining IP information for nm-bridge... failed; no link present. Check cable? Jul 06 13:00:48 server1.example.com network[996]: [FAILED] Jul 06 13:00:48 server1.example.com systemd[1]: network.service: control process exited, code=exited status=1 Jul 06 13:00:48 server1.example.com systemd[1]: Failed to start LSB: Bring up/down networking. Jul 06 13:00:48 server1.example.com systemd[1]: Unit network.service entered failed state. Jul 06 13:00:48 server1.example.com systemd[1]: network.service failed. 8. systemctl restart network 9. 'journalctl -xe' now contains: Jul 06 13:06:57 server1.example.com network[2796]: Bringing up interface br0: Jul 06 13:06:57 server1.example.com dhclient[3251]: DHCPREQUEST on nm-bridge to 255.255.255.255 port 67 (xid=0x3c9dd4c3) Jul 06 13:06:57 server1.example.com dhclient[3251]: DHCPACK from 192.168.100.1 (xid=0x3c9dd4c3) Jul 06 13:07:00 server1.example.com network[2796]: Determining IP information for nm-bridge... done. Jul 06 13:07:01 server1.example.com network[2796]: [ OK ] Actual results: Bridge interface cannot get a DHCP assigned IP during boot. Restarting network allows bridge interface to get a DHCP assigned IP. Expected results: Bridge interface should get a DHCP assigned IP during boot. Additional info: