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 1303968 - NetworkManager Bridged Team MTU Fails to Set
Summary: NetworkManager Bridged Team MTU Fails to Set
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
: 1303731 1316590 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-02 14:44 UTC by Trae Santiago
Modified: 2020-09-21 07:31 UTC (History)
8 users (show)

Fixed In Version: NetworkManager-1.4.0-0.1.git20160606.b769b4df.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 19:07:13 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
/var/log/messages (27.37 KB, text/plain)
2016-02-02 14:44 UTC, Trae Santiago 		no flags Details
[PATCH] device: apply MTU setting also to devices without IPv4 configuration (3.96 KB, patch)
2016-03-17 14:18 UTC, Beniamino Galvani 		no flags Details | Diff
[PATCH v2] device: apply MTU setting also to devices without IPv4 configuration (3.13 KB, patch)
2016-03-22 09:35 UTC, Beniamino Galvani 		no flags Details | Diff
Show Obsolete (1) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2195741 0 None None None 2017-01-12 23:49:47 UTC
Red Hat Product Errata RHSA-2016:2581 0 normal SHIPPED_LIVE Low: NetworkManager security, bug fix, and enhancement update 2016-11-03 12:08:07 UTC

Description Trae Santiago 2016-02-02 14:44:45 UTC 
Created attachment 1120463 [details]
/var/log/messages

Note: I'm not sure if it matters, but this server was upgraded from 7.0-1406 to the current release (as of today). As well, this seems to be similar in nature to https://bugzilla.redhat.com/show_bug.cgi?id=1275035

Description of problem:
Setting the MTU on a bridged team has no effect on the actual MTU. While the configuration does show that the MTU should be 9000, both 'ip' and 'ifconfig' show the links as being set for 1500. MTU gets set fine without a bridge.

Version-Release number of selected component (if applicable):
[root@kvm01-centos7 ~]# NetworkManager -V
1.0.6-27.el7

How reproducible:
Always

Steps to Reproduce:
1. Create and configure a bridge:
nmcli c add type bridge con-name br0 ifname br0
nmcli c modify br0 connection.zone internal 802-3-ethernet.mtu 9000 ipv4.method manual ipv4.dns '10.0.80.11 10.0.80.12' ipv4.addresses '10.120.19.87/26' ipv4.gateway '10.120.19.65' ipv4.routes '10.0.0.0/8 10.120.19.65 0' ipv6.method ignore

2. Create and configure a team:
nmcli c add type team con-name team0 ifname team0
nmcli c modify team0 connection.zone internal 802-3-ethernet.mtu 9000 team.config team0.cfg connection.slave-type bridge connection.master br0 

3. Create and configure 2 slaves:
nmcli c add type team-slave con-name team0-slave0 ifname ens18f0 master team0
nmcli c modify team0-slave0 connection.zone internal 802-3-ethernet.mtu 9000
nmcli c add type team-slave con-name team0-slave1 ifname enp3s0f0 master team0
nmcli c modify team0-slave1 connection.zone internal 802-3-ethernet.mtu 9000

4. Re-initialize all the things:
nmcli c up br0
nmcli c up team0
nmcli c up team0-slave0
nmcli c up team0-slave1

5. Test your connection:
ping -c4 10.0.80.11

6. View the MTU:
ip link

Actual results:
MTU not set to 9000

Expected results:
MTU set to 9000
MTU set to 9000

Additional info:
Here's what it looked like:
[root@kvm01-centos7 ~]# nmcli c add type bridge con-name br0 ifname br0                                                         
Connection 'br0' (b78cf8ed-0e6b-43b0-bd6a-31cf507fddc5) successfully added.                                                     
[root@kvm01-centos7 ~]# nmcli c modify br0 connection.zone internal 802-3-ethernet.mtu 9000 ipv4.method manual ipv4.dns '10.0.80
.11 10.0.80.12' ipv4.addresses '10.120.19.87/26' ipv4.gateway '10.120.19.65' ipv4.routes '10.0.0.0/8 10.120.19.65 0' ipv6.method
 ignore                                                                                                                         
[root@kvm01-centos7 ~]# nmcli c add type team con-name team0 ifname team0                                                       
Connection 'team0' (72c585d1-98df-4799-9115-ecf259e65729) successfully added.                                                   
[root@kvm01-centos7 ~]# nmcli c modify team0 connection.zone internal 802-3-ethernet.mtu 9000 team.config team0.cfg connection.s
lave-type bridge connection.master br0                                                                                          
[root@kvm01-centos7 ~]# nmcli c add type team-slave con-name team0-slave0 ifname ens18f0 master team0                           
Connection 'team0-slave0' (10c5c615-f4d8-43f8-a1f3-1ea23bc58133) successfully added.                                            
[root@kvm01-centos7 ~]# nmcli c modify team0-slave0 connection.zone internal 802-3-ethernet.mtu 9000                            
[root@kvm01-centos7 ~]# nmcli c add type team-slave con-name team0-slave1 ifname enp3s0f0 master team0                          
Connection 'team0-slave1' (a4096eaa-4a21-4f12-8b5d-340c7693366f) successfully added.                                            
[root@kvm01-centos7 ~]# nmcli c modify team0-slave1 connection.zone internal 802-3-ethernet.mtu 9000                            
[root@kvm01-centos7 ~]# nmcli c up br0                                                                                          
Connection successfully activated (master waiting for slaves) (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnecti
on/27)                                                                                                                          
[root@kvm01-centos7 ~]# nmcli c up team0                                                                                        
Connection successfully activated (master waiting for slaves) (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnecti
on/28)                                                                                                                          
[root@kvm01-centos7 ~]# nmcli c up team0-slave0                                                                                 
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/31)                      
[root@kvm01-centos7 ~]# nmcli c up team0-slave1                                                                                 
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/32)                      
[root@kvm01-centos7 ~]# ping -c4 10.0.80.11                                                                  
PING 10.0.80.11 (10.0.80.11) 56(84) bytes of data.                                                           
64 bytes from 10.0.80.11: icmp_seq=1 ttl=253 time=4.96 ms                                                    
64 bytes from 10.0.80.11: icmp_seq=2 ttl=253 time=0.113 ms                                                   
64 bytes from 10.0.80.11: icmp_seq=3 ttl=253 time=0.113 ms                                                   
64 bytes from 10.0.80.11: icmp_seq=4 ttl=253 time=0.122 ms                                                   
                                                                                                             
--- 10.0.80.11 ping statistics ---                                                                           
4 packets transmitted, 4 received, 0% packet loss, time 3001ms                                               
rtt min/avg/max/mdev = 0.113/1.329/4.969/2.101 ms                                                            
[root@kvm01-centos7 ~]# ip l                                                                                 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT                             
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00                                                    
2: ens18f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master team0 state UP mode DEFAULT qlen 1000 
    link/ether 0c:c4:7a:39:4d:06 brd ff:ff:ff:ff:ff:ff                                                       
3: ens18f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master team1 state UP mode DEFAULT qlen 1000 
    link/ether 0c:c4:7a:39:4d:07 brd ff:ff:ff:ff:ff:ff                                                       
4: enp3s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master team0 state UP mode DEFAULT qlen 1000
    link/ether 0c:c4:7a:39:4d:06 brd ff:ff:ff:ff:ff:ff                                                       
5: enp3s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master team1 state UP mode DEFAULT qlen 1000
    link/ether 0c:c4:7a:39:4d:07 brd ff:ff:ff:ff:ff:ff                                                       
19: team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP mode DEFAULT         
    link/ether 0c:c4:7a:39:4d:06 brd ff:ff:ff:ff:ff:ff                                                       
20: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT                      
    link/ether 0c:c4:7a:39:4d:06 brd ff:ff:ff:ff:ff:ff                                                       
21: team1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br1 state UP mode DEFAULT         
    link/ether 0c:c4:7a:39:4d:07 brd ff:ff:ff:ff:ff:ff                                                       
22: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT                      
    link/ether 0c:c4:7a:39:4d:07 brd ff:ff:ff:ff:ff:ff
Comment 1 Trae Santiago 2016-02-02 14:45:52 UTC 
Please ignore the terrible formatting of output, I had to copy and paste.
Comment 3 Beniamino Galvani 2016-02-15 13:00:03 UTC 
The MTU is not set because the team connection doesn't have any IP configuration and we change the MTU in ip4_config_pre_commit() of nm-device-team.c; probably we should move the change of MTU to another callback that runs also when there is no IP configuration.
Comment 4 Beniamino Galvani 2016-03-17 14:18:46 UTC 
Created attachment 1137401 [details]
[PATCH] device: apply MTU setting also to devices without IPv4 configuration

Patch for master.
Comment 5 Beniamino Galvani 2016-03-17 14:49:52 UTC 
*** Bug 1303731 has been marked as a duplicate of this bug. ***
Comment 6 Thomas Haller 2016-03-17 16:15:53 UTC 
(In reply to Beniamino Galvani from comment #4)
> Created attachment 1137401 [details]
> [PATCH] device: apply MTU setting also to devices without IPv4 configuration
> 
> Patch for master.

+static void
+nm_device_apply_mtu_from_config (NMDevice *self)

I would name static methods without nm_ prefix (although there are counter examples).




+              _LOGE (LOGD_DEVICE | LOGD_IP,
+                     "setting MTU of device without IP4 config to %u",

_LOGD?



Rest lgtm
Comment 7 Beniamino Galvani 2016-03-22 09:35:24 UTC 
Created attachment 1138952 [details]
[PATCH v2] device: apply MTU setting also to devices without IPv4 configuration

(In reply to Thomas Haller from comment #6)
> I would name static methods without nm_ prefix (although there are counter
> examples).

> _LOGD?

Both fixed, thanks.
Comment 8 Beniamino Galvani 2016-03-22 09:43:16 UTC 
*** Bug 1316590 has been marked as a duplicate of this bug. ***
Comment 9 Mike McCune 2016-03-28 22:20:08 UTC 
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Comment 10 Thomas Haller 2016-03-29 13:08:26 UTC 
(In reply to Beniamino Galvani from comment #7)
> Created attachment 1138952 [details]
> [PATCH v2] device: apply MTU setting also to devices without IPv4
> configuration
> 
> (In reply to Thomas Haller from comment #6)
> > I would name static methods without nm_ prefix (although there are counter
> > examples).
> 
> > _LOGD?
> 
> Both fixed, thanks.

LGTM now.
Comment 11 Francesco Giudici 2016-04-14 13:14:51 UTC 
(In reply to Beniamino Galvani from comment #7)
> Created attachment 1138952 [details]
> [PATCH v2] device: apply MTU setting also to devices without IPv4
> configuration

LGTM
Comment 12 Beniamino Galvani 2016-04-14 13:23:03 UTC 
Merged to master:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=53dfaddda2adad15f4fbf35780bc03503cc45a63
Comment 17 Vladimir Benes 2016-06-30 10:52:27 UTC 
works fine now, mtu 9000 is set from slave over team to bridge
Comment 22 errata-xmlrpc 2016-11-03 19:07:13 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-2016-2581.html
Note You need to log in before you can comment on or make changes to this bug.