Bug 1275035 - NetworkManager Bond MTU Fails to Set
NetworkManager Bond MTU Fails to Set
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
7.1
All Linux
medium Severity medium
: rc
: ---
Assigned To: Rashid Khan
Desktop QE
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-25 03:17 EDT by Trae Santiago
Modified: 2016-02-02 06:27 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-02 06:27:00 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages (181.82 KB, text/plain)
2015-10-25 03:17 EDT, Trae Santiago
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
CentOS 9632 None None None Never

  None (edit)
Description Trae Santiago 2015-10-25 03:17:27 EDT
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 03:25:24 EDT
I forgot to mention a somewhat obvious step:
5. Re-initialize the connections:
nmcli c up bond0
Comment 5 Jirka Klimes 2015-12-18 07:34:10 EST
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 04:05:07 EST
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 05:28:18 EST
(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 06:17:27 EST
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 06:27:00 EST
Ok, closing again.

yes, please open a new bug.


Thank you!!

Note You need to log in before you can comment on or make changes to this bug.