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.
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):
Steps to Reproduce:
1. Contents of /etc/sysconfig/network-scripts/ifcfg-team0-eth1
2. Contents of /etc/sysconfig/network-scripts/ifcfg-team0-eth2
3. Contents of /etc/sysconfig/network-scripts/ifcfg-team0
4. Contents of /etc/sysconfig/network-scripts/ifcfg-bridge
5. systemctl mask NetworkManager.service
6. Reboot system
7. 'journalctl -xe' contains:
Jul 06 13:00:41 server1.example.com network: Bringing up interface br0:
Jul 06 13:00:48 server1.example.com network: Determining IP information for nm-bridge... failed; no link present. Check cable?
Jul 06 13:00:48 server1.example.com network: [FAILED]
Jul 06 13:00:48 server1.example.com systemd: network.service: control process exited, code=exited status=1
Jul 06 13:00:48 server1.example.com systemd: Failed to start LSB: Bring up/down networking.
Jul 06 13:00:48 server1.example.com systemd: Unit network.service entered failed state.
Jul 06 13:00:48 server1.example.com systemd: network.service failed.
8. systemctl restart network
9. 'journalctl -xe' now contains:
Jul 06 13:06:57 server1.example.com network: Bringing up interface br0:
Jul 06 13:06:57 server1.example.com dhclient: DHCPREQUEST on nm-bridge to 255.255.255.255 port 67 (xid=0x3c9dd4c3)
Jul 06 13:06:57 server1.example.com dhclient: DHCPACK from 192.168.100.1 (xid=0x3c9dd4c3)
Jul 06 13:07:00 server1.example.com network: Determining IP information for nm-bridge... done.
Jul 06 13:07:01 server1.example.com network: [ OK ]
Bridge interface cannot get a DHCP assigned IP during boot. Restarting network allows bridge interface to get a DHCP assigned IP.
Bridge interface should get a DHCP assigned IP during boot.
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)
Created attachment 1206006 [details]
Proposed patch for initscripts-9.49.30-1.3
Any updates regarding this bug ?
(In reply to Strahil Nikolov from comment #5)
> Any updates regarding this bug ?
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.