| Summary: | Bridge device cannot get ip from dhcp when connected to teamed device (no link available). After restart of network - works | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Richard D Alloway <ralloway> | ||||
| Component: | initscripts | Assignee: | David Kaspar // Dee'Kej <deekej> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Daniel Rusek <drusek> | ||||
| Severity: | medium | Docs Contact: | Petr Bokoc <pbokoc> | ||||
| Priority: | medium | ||||||
| Version: | 7.2 | CC: | deekej, drusek, hunter86_bg, jscotka, ralloway | ||||
| Target Milestone: | rc | Keywords: | Patch | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| 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 18:24:45 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | Engineering1380361 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
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 ? https://github.com/fedora-sysv/initscripts/pull/112 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 |
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: