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 1275035 - NetworkManager Bond MTU Fails to Set
Summary: NetworkManager Bond MTU Fails to Set
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Rashid Khan
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-25 07:17 UTC by Trae Santiago
Modified: 2016-02-02 11:27 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-02 11:27:00 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
CentOS 9632 0 None None None Never

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 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!!


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