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 1380496 - Bridge device cannot get ip from dhcp when connected to teamed device (no link available). After restart of network - works
Summary: Bridge device cannot get ip from dhcp when connected to teamed device (no lin...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: initscripts
Version: 7.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: David Kaspar // Dee'Kej
QA Contact: Daniel Rusek
Petr Bokoc
URL:
Whiteboard:
Depends On: 1380361
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-29 18:49 UTC by Richard D Alloway
Modified: 2023-09-25 22:54 UTC (History)
6 users (show)

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.
Clone Of:
Environment:
Last Closed: 2018-04-10 18:24:45 UTC
Target Upstream Version:
Embargoed:

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


Links
System ID Private Priority Status Summary Last Updated
CentOS 0011138 0 None None None 2016-09-29 18:49:50 UTC
Red Hat Product Errata RHBA-2018:0983 0 None None None 2018-04-10 18:26:24 UTC

Description Richard 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 1 Richard 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 2 Richard D Alloway 2016-09-29 18:52:40 UTC 
Created attachment 1206006 [details]
Proposed patch for initscripts-9.49.30-1.3
Comment 5 Strahil Nikolov 2017-07-16 15:26:53 UTC 
Any updates regarding this bug ?
Comment 6 David Kaspar // Dee'Kej 2017-07-21 12:11:43 UTC 
(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 18:24:45 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 12 zeloaipi 2023-06-22 01:39:43 UTC Comment hidden (spam)
Comment 13 Lynn Davenport 2023-09-25 08:29:41 UTC Comment hidden (spam)
Note You need to log in before you can comment on or make changes to this bug.