Bug 1275035

Summary: NetworkManager Bond MTU Fails to Set
Product: Red Hat Enterprise Linux 7 Reporter: Trae Santiago <tsantiago>
Component: NetworkManagerAssignee: Rashid Khan <rkhan>
Status: CLOSED CURRENTRELEASE QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: aloughla, bgalvani, dcbw, jklimes, lrintel, rkhan, thaller, trae32566, tsantiago
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-02 11:27:00 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:
Embargoed:
Attachments:
Description Flags
/var/log/messages none

Description Trae Santiago 2015-10-25 07:17:27 UTC 
Created attachment 1086169 [details]
/var/log/messages

Description of problem:
Setting the MTU on a bond (or the bond slaves) 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. 

Things that do work:
Setting the MTU via 'ip':
    ip link set bond0 mtu 9000

Turning NetworkManager off, and network back on: 
    systemctl stop NetworkManager.service
    systemctl start network.service


How reproducible:
Always

Steps to Reproduce:
1. Create a bond:
nmcli c add type bond con-name bond0 ifname bond0

2. Create 2 slaves:
nmcli c add type bond-slave con-name bond0-slave0 ifname <interface_1> master bond0
nmcli c add type bond-slave con-name bond0-slave1 ifname <interface_2> master bond0

3. Set your required parameters (this is dependent on your specific requirements, in my case this was LACP with lacp_rate=fast, along with some static IP info):
# nmcli c modify bond0 ...

4. Set the MTU on the slaves:
nmcli c modify bond0-slave0 802-3-ethernet.mtu 9000
nmcli c modify bond0-slave1 802-3-ethernet.mtu 9000


Actual results:
MTU not set to 9000

Expected results:
MTU set to 9000

Additional info:
I did try setting the MTU on the bond as well:
nmcli c modify bond0 802-3-ethernet.mtu 9000

This made no difference at all.

I did find something I thought potentially relevant when searching around:
http://marc.info/?l=e1000-devel&m=137004039108290&w=2

As well, /var/log/messages shows several messages about the MTU getting set, and I believe this could be part of the issue.
Comment 1 Trae Santiago 2015-10-25 07:25:24 UTC 
I forgot to mention a somewhat obvious step:
5. Re-initialize the connections:
nmcli c up bond0
Comment 3 Jirka Klimes 2015-10-27 14:44:47 UTC 
This has been fixed in bug 1177860 and will be delivered in RHEL 7.2.

Upstream commit:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-0&id=5359322b6dcac8cdf7a26464f995f2b097618ca7

and
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-0&id=33ee3b2a496133fb532e02838570fdae72f63275
Comment 5 Jirka Klimes 2015-12-18 12:34:10 UTC 
Just a note, if a connection profile is changed, it is not re-applied automatically. It has to be activated manually so that the changes could appear on device, like:
$ nmcli con up bond0-slave0

(restarting NetworkManager does it too as long as the profiles has autoconnect property set)
Comment 6 Trae Santiago 2016-02-02 09:05:07 UTC 
Hello,

It appears that this is fixed only for new servers (ie: a yum upgrade will not fix the issue). I've tested this both with the server originally exhibiting the issue, and with a new server which was installed using 7.0 media and upgraded to 7.2. Has the issue been verified as fixed on an existing server? Perhaps I'm doing something wrong.

Thanks,

Trae S.
Comment 7 Thomas Haller 2016-02-02 10:28:18 UTC 
(In reply to Trae Santiago from comment #6)
> Hello,
> 
> It appears that this is fixed only for new servers (ie: a yum upgrade will
> not fix the issue). I've tested this both with the server originally
> exhibiting the issue, and with a new server which was installed using 7.0
> media and upgraded to 7.2. Has the issue been verified as fixed on an
> existing server? Perhaps I'm doing something wrong.

yum upgrade doesn't restart the NetworkManager service, but I assume you rebooted after the upgrade anyway?

I assume you activated the connection anew after modifying the MTU (like `nmcli connection up bond0`)?

It's not very likely that NetworkManager behaves differently depending on whether you got the package from a fresh-installation or from an upgrade.

What is your NetworkManager version?
Comment 8 Trae Santiago 2016-02-02 11:17:27 UTC 
I found the issue, I apologize. I do have a relevant issue with teaming, basically the same issue regarding MTU, but I should probably open a new bug report for that I'm guessing? 

Thanks for the quick response!
Comment 9 Thomas Haller 2016-02-02 11:27:00 UTC 
Ok, closing again.

yes, please open a new bug.


Thank you!!