Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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
(In reply to Thomas Haller from comment #9)
> Fix on review in upstream branch: th/enslave-team-rh1183444
The fix looks good to me.
Comment 11Beniamino Galvani
2015-10-02 13:46:13 UTC
> 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! ?
Comment 13Beniamino Galvani
2015-10-02 14:15:02 UTC
(In reply to Thomas Haller from comment #12)
> Oh right. How about the fixup! ?
Looks good.
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.
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
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.