Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1380496 - Bridge device cannot get ip from dhcp when connected to teamed device (no link available). After restart of network - works
Bridge device cannot get ip from dhcp when connected to teamed device (no lin...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: initscripts (Show other bugs)
7.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: David Kaspar [Dee'Kej]
Daniel Rusek
Petr Bokoc
: Patch
Depends On: 1380361
Blocks:
  Show dependency treegraph
 
Reported: 2016-09-29 14:49 EDT by Richard D Alloway
Modified: 2018-04-10 14:26 EDT (History)
5 users (show)

See Also:
Fixed In Version: initscripts-9.49.40-2.el7
Doc Type: Release Note
Doc Text:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-10 14:24:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch for initscripts-9.49.30-1.3 (3.32 KB, patch)
2016-09-29 14:52 EDT, Richard D Alloway
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
CentOS 0011138 None None None 2016-09-29 14:49 EDT
Red Hat Product Errata RHBA-2018:0983 None None None 2018-04-10 14:26 EDT

  None (edit)
Description Richard D Alloway 2016-09-29 14:49:50 EDT
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 1 Richard D Alloway 2016-09-29 14:50:50 EDT
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 2 Richard D Alloway 2016-09-29 14:52 EDT
Created attachment 1206006 [details]
Proposed patch for initscripts-9.49.30-1.3
Comment 5 Strahil Nikolov 2017-07-16 11:26:53 EDT
Any updates regarding this bug ?
Comment 6 David Kaspar [Dee'Kej] 2017-07-21 08:11:43 EDT
(In reply to Strahil Nikolov from comment #5)
> Any updates regarding this bug ?

https://github.com/fedora-sysv/initscripts/pull/112
Comment 11 errata-xmlrpc 2018-04-10 14:24:45 EDT
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

Note You need to log in before you can comment on or make changes to this bug.