Bug 1323627

Summary: NetworkManager ignores MTU
Product: [Fedora] Fedora Reporter: Stuart James <stuartjames>
Component: NetworkManagerAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: dcbw, lkundrak, psimerda
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-20 19:47:13 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:

Description Stuart James 2016-04-04 09:49:51 UTC
Description of problem:

Configure a network device and associated bridge device. Start both devices automatically on boot using NetworkManager (default). This has negative effect on Libvirt hosts using larger MTU as TCP connections hang without other servers on network that are using MTU of 1600.


Version-Release number of selected component (if applicable):

Fedora release 23 (Twenty Three)
NetworkManager-1.0.12-1.fc23.x86_64
kernel-core-4.4.6-300.fc23.x86_64


How reproducible:


Steps to Reproduce:
1. Configure two devices

BRIDGE0
/etc/sysconfig/network-scripts/ifcfg-Bridge_connection_1
DEVICE=bridge0
STP=yes
TYPE=Bridge
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME="Bridge connection 1"
UUID=ccd92893-d819-4d84-9211-e7e86bf4c1a7
ONBOOT=yes
DNS1=192.168.0.1
DOMAIN=jamesnet.ca
BRIDGING_OPTS=priority=32768
IPADDR=192.168.0.222
PREFIX=24
GATEWAY=192.168.0.1
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_PRIVACY=no
MTU=1600

(i realize that MTU in bridge type is not supported but i put it there just in case, i can see this by dumping the nmcli of the connection)

ENP2S0 (physical ethernet)
/etc/sysconfig/network-scripts/ifcfg-bridge0_slave_1
HWADDR=90:2B:34:3E:3D:99
TYPE=Ethernet
NAME="bridge0 slave 1"
UUID=5d2317b6-4bec-48f5-9986-a91ffcf4ba1c
DEVICE=enp2s0
ONBOOT=yes
BRIDGE=bridge0
MTU=1600


2. Start up computer


Actual results:
The MTU of bridge0 and enp2s0 is 1500 where is should be 1600.

2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge0 state UP mode DEFAULT group default qlen 1000
    link/ether 90:2b:34:3e:3d:99 brd ff:ff:ff:ff:ff:ff
3: bridge0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 90:2b:34:3e:3d:99 brd ff:ff:ff:ff:ff:ff


Expected results:
The MTU should be 1600 when interfaces are started.


Additional info:
nmcli connection show 5d2317b6-4bec-48f5-9986-a91ffcf4ba1c
connection.id:                          bridge0 slave 1
connection.uuid:                        5d2317b6-4bec-48f5-9986-a91ffcf4ba1c
connection.interface-name:              enp2s0
connection.type:                        802-3-ethernet
connection.autoconnect:                 yes
connection.autoconnect-priority:        0
connection.timestamp:                   1459762288
connection.read-only:                   no
connection.permissions:                 
connection.zone:                        --
connection.master:                      bridge0
connection.slave-type:                  bridge
connection.autoconnect-slaves:          -1 (default)
connection.secondaries:                 
connection.gateway-ping-timeout:        0
connection.metered:                     unknown
802-3-ethernet.port:                    --
802-3-ethernet.speed:                   0
802-3-ethernet.duplex:                  --
802-3-ethernet.auto-negotiate:          yes
802-3-ethernet.mac-address:             90:2B:34:3E:3D:99
802-3-ethernet.cloned-mac-address:      --
802-3-ethernet.mac-address-blacklist:   
802-3-ethernet.mtu:                     1600
802-3-ethernet.s390-subchannels:        
802-3-ethernet.s390-nettype:            --
802-3-ethernet.s390-options:            
802-3-ethernet.wake-on-lan:             1 (default)
802-3-ethernet.wake-on-lan-password:    --
bridge-port.priority:                   32
bridge-port.path-cost:                  100
bridge-port.hairpin-mode:               no
GENERAL.NAME:                           bridge0 slave 1
GENERAL.UUID:                           5d2317b6-4bec-48f5-9986-a91ffcf4ba1c
GENERAL.DEVICES:                        enp2s0
GENERAL.STATE:                          activated
GENERAL.DEFAULT:                        no
GENERAL.DEFAULT6:                       no
GENERAL.VPN:                            no
GENERAL.ZONE:                           --
GENERAL.DBUS-PATH:                      /org/freedesktop/NetworkManager/ActiveConnection/0
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/Settings/0
GENERAL.SPEC-OBJECT:                    /
GENERAL.MASTER-PATH:                    /org/freedesktop/NetworkManager/Devices/1
IP4.GATEWAY:                            
IP6.GATEWAY:                            


By using the following command manually sets it, virtual machines with vnetx must be stopped and started.
ip link set dev enp2s0 mtu 1600


I also tested this on latest RHEL 7.2 , it appears to work as expect on a single 
 interface(so if i specify enp2s0 with MTU of 1600 and no bridge) but when i do the bridged interface it seems to always default back to 1500.

Comment 1 Stuart James 2016-04-04 14:54:12 UTC
I did some more testing on this, disabling NetworkManager using sytemctl (configuring NM_CONTROLLED=no to make sure) enabling network.service and the problem persists.

It appears the issue is more related to how bridge module and device is loaded and default is to set 1500 MTU, i found a bug report https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1399064 which also describes this issue without resolution.

The fundamental problem here is that you want to create a network bridge for virtual machines to use that the virtual machines can set higher MTU's on, however when bridge0 starts it has an MTU of 1500 even if the slave the device is configured to have MTU of 1600 as per my configuration.

https://www.redhat.com/archives/libvir-list/2008-December/msg00083.html

IMHO if the slave (enp2s0) is configured to have MTU 1600 then the bridge should utilize the slave MTU, this might be complex if you have two or more slaves (bonded configuration) where by the MTU do not match. The alternative is to allow MTU to be configured on the bridge itself and force the slaves to use this MTU, this may require subsequent "ip link set" commands but currently without this i do not see how i can get vms inside on a bridge to use higher MTU's as all these devices (enp2s0, br0, vnetx on host and eth0 on vm must have corresponding or minimum of eth0 to work correctly)

Comment 2 Fedora End Of Life 2016-11-25 07:14:44 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 Fedora End Of Life 2016-12-20 19:47:13 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.