Red Hat Bugzilla – Bug 1275035
NetworkManager Bond MTU Fails to Set
Last modified: 2016-02-02 06:27:00 EST
Created attachment 1086169 [details]
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
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
MTU not set to 9000
MTU set to 9000
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:
As well, /var/log/messages shows several messages about the MTU getting set, and I believe this could be part of the issue.
I forgot to mention a somewhat obvious step:
5. Re-initialize the connections:
nmcli c up bond0
This has been fixed in bug 1177860 and will be delivered in RHEL 7.2.
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)
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.
(In reply to Trae Santiago from comment #6)
> 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?
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!
Ok, closing again.
yes, please open a new bug.