Red Hat Bugzilla – Bug 1183444
Attaching a team device to a bridge doesn't work.
Last modified: 2016-12-08 12:16:13 EST
Description of problem: Attaching a team device to a bridge doesn't work. Version-Release number of selected component (if applicable): # cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.0 (Maipo) # rpm -qa | grep NetworkManager NetworkManager-glib-0.9.9.1-29.git20140326.4dba720.el7_0.x86_64 NetworkManager-0.9.9.1-29.git20140326.4dba720.el7_0.x86_64 NetworkManager-config-server-0.9.9.1-29.git20140326.4dba720.el7_0.x86_64 NetworkManager-tui-0.9.9.1-29.git20140326.4dba720.el7_0.x86_64 # uname -a Linux rhel7 3.10.0-123.13.2.el7.x86_64 #1 SMP Fri Dec 12 19:51:03 EST 2014 x86_64 x86_64 x86_64 GNU/Linux Steps to Reproduce: 1. Intended configuration ens6 -| |-- team0 -- br0 (192.168.1.11) ens7 -| 2. Create a bridge br0 # nmcli c add type bridge ifname br0 con-name bridge-br0 # nmcli c mod bridge-br0 bridge.stp no # nmcli c mod bridge-br0 ipv4.method manual ipv4.addresses "192.168.1.11/24 192.168.1.1" # nmcli c mod bridge-br0 ipv4.dns 8.8.8.8 ipv4.dns-search redhat.com # nmcli c down bridge-br0 # nmcli c up bridge-br0 3. Create a team device team0 with a dummy IP. # nmcli c add type team ifname team0 con-name team-team0 # nmcli c mod team-team0 ipv4.method manual ipv4.addresses "127.0.0.2/8" # nmcli c add type team-slave ifname ens6 con-name team-slave-ens6 master team-team0 # nmcli c add type team-slave ifname ens7 con-name team-slave-ens7 master team-team0 At this point, the dummy IP is actually assigned as intened. # nmcli -f ipv4.addresses c show team-team0 ipv4.addresses: { ip = 127.0.0.2/8, gw = 0.0.0.0 } 4. Attach it to a bridge br0. # nmcli c mod team-team0 connection.master br0 # nmcli c mod team-team0 connection.slave-type bridge But with this, ipv4 props are all dropped from team0 # nmcli -f ipv4.addresses c show team-team0 Because of this, when activating the connection, it keeps trying to get IP via DHCP and fails to be active. # nmcli c up team-slave-ens6 # nmcli c up team-slave-ens7 # nmcli c up team-team0 Error: Timeout 90 sec expired. # nmcli d DEVICE TYPE STATE CONNECTION br0 bridge connected bridge-br0 ens6 ethernet connected team-slave-ens6 ens7 ethernet connected team-slave-ens7 eth0 ethernet connected eth0 team0 team connecting (getting IP configuration) team-team0 lo loopback unmanaged -- Expected results: If ipv4 props are dropped, it shouldn't use DHCP, and be active without IP.
Hi, The behavior has slightly changed in RHEL7.1GA and it doesn't timed out on surface. But, it still has the same problem. Thought the last command succeeds, team0 keeps trying to have IP via DHCP in the background. And it doesn't attach to the bridge br0. # nmcli d DEVICE TYPE STATE CONNECTION br0 bridge connected bridge-br0 eth0 ethernet connected eth0 eth1 ethernet connected team-slave-eth1 eth2 ethernet connected team-slave-eth2 team0 team connecting (getting IP configuration) team-team0 lo loopback unmanaged -- # brctl show bridge name bridge id STP enabled interfaces br0 8000.000000000000 no The following is the commands to recreate this. # nmcli c add type bridge ifname br0 con-name bridge-br0 # nmcli c mod bridge-br0 bridge.stp no # nmcli c mod bridge-br0 ipv4.method manual ipv4.addresses "192.168.1.11/24" ipv4.gateway "192.168.1.1" # nmcli c mod bridge-br0 ipv4.dns 8.8.8.8 ipv4.dns-search redhat.com # nmcli c down bridge-br0 # nmcli c up bridge-br0 # nmcli c add type team ifname team0 con-name team-team0 # nmcli c mod team-team0 ipv4.method manual ipv4.addresses "127.0.0.2/8" # nmcli c add type team-slave ifname eth1 con-name team-slave-eth1 master team-team0 # nmcli c add type team-slave ifname eth2 con-name team-slave-eth2 master team-team0 # nmcli c mod team-team0 connection.master br0 connection.slave-type bridge # nmcli c up team-slave-eth1 # nmcli c up team-slave-eth2 # nmcli c up team-team0
Fix on review in upstream branch: th/enslave-team-rh1183444
(In reply to Thomas Haller from comment #9) > Fix on review in upstream branch: th/enslave-team-rh1183444 The fix looks good to me.
> device: fix activating slave device when stage1 delays action @@ nm_device_activate_stage2_device_config (gpointer user_data) + if (nm_active_connection_get_master_ready (active)) + master_ready_cb (active, NULL, self); I'm trying to understand, won't master_ready_cb() schedule stage2_device_config again and so it will be executed 2 times?
(In reply to Beniamino Galvani from comment #11) > > device: fix activating slave device when stage1 delays action > > @@ nm_device_activate_stage2_device_config (gpointer user_data) > + if (nm_active_connection_get_master_ready (active)) > + master_ready_cb (active, NULL, self); > > I'm trying to understand, won't master_ready_cb() schedule > stage2_device_config again and so it will be executed 2 times? Oh right. How about the fixup! ?
(In reply to Thomas Haller from comment #12) > Oh right. How about the fixup! ? Looks good.
merged upstream: master: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=18b20c4f6f9f2961ea79c96b9a56116d556103c9 nm-1-0: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=9796eace518c18fbde1fda1f8c4cced91e710f8c
Yeah, there was a bug there :( Fixed upstream now: master: c41be46 device: assert that master-ready handler is not scheduled in schedule_stage2_device_config() 7bbc090 device: handle master-ready before scheduling stage2 c5210b3 device: fix activating master/slave devices during stage2 nm-1-0: 4e0882e device: assert that master-ready handler is not scheduled in schedule_stage2_device_config() 7828003 device: handle master-ready before scheduling stage2 5c20dd9 device: fix activating master/slave devices during stage2 Backported these patches.
*** Bug 1268797 has been marked as a duplicate of this bug. ***
team as well as bond work now and can be both attached into bridge
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://rhn.redhat.com/errata/RHSA-2015-2315.html