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 1183444 - Attaching a team device to a bridge doesn't work.
Summary: Attaching a team device to a bridge doesn't work.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Thomas Haller
QA Contact: Desktop QE
URL:
Whiteboard:
: 1268797 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-19 04:06 UTC by Etsuji Nakai
Modified: 2016-12-08 17:16 UTC (History)
16 users (show)

Fixed In Version: NetworkManager-1.0.6-15.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 10:59:41 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:2315 0 normal SHIPPED_LIVE Moderate: NetworkManager security, bug fix, and enhancement update 2015-11-19 10:06:58 UTC

Description Etsuji Nakai 2015-01-19 04:06:14 UTC 
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.
Comment 8 Etsuji Nakai 2015-05-23 00:38:29 UTC 
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
Comment 9 Thomas Haller 2015-10-01 15:20:02 UTC 
Fix on review in upstream branch: th/enslave-team-rh1183444
Comment 10 Jirka Klimes 2015-10-02 08:43:51 UTC 
(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 11 Beniamino 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?
Comment 12 Thomas Haller 2015-10-02 14:08:26 UTC 
(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 13 Beniamino Galvani 2015-10-02 14:15:02 UTC 
(In reply to Thomas Haller from comment #12)
> Oh right. How about the fixup! ?

Looks good.
Comment 14 Thomas Haller 2015-10-02 16:54:36 UTC 
merged upstream:

master: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=18b20c4f6f9f2961ea79c96b9a56116d556103c9

nm-1-0: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=9796eace518c18fbde1fda1f8c4cced91e710f8c
Comment 16 Thomas Haller 2015-10-06 16:13:11 UTC 
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.
Comment 18 Thomas Haller 2015-10-07 15:02:45 UTC 
*** Bug 1268797 has been marked as a duplicate of this bug. ***
Comment 19 Vladimir Benes 2015-10-08 07:23:57 UTC 
team as well as bond work now and can be both attached into bridge
Comment 20 errata-xmlrpc 2015-11-19 10:59:41 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://rhn.redhat.com/errata/RHSA-2015-2315.html
Note You need to log in before you can comment on or make changes to this bug.