Hide Forgot
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.
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)
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.
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.