Description of problem: VLAN interfaces with different MTU values can be added to OVS bridge successfully, but if physical interface is added to the same bridge then all VLAN MTU values will be set to the same value as that physical interface has. Logic is not even consistent since after the physical interface is added to the bridge, one can again add VLAN interfaces with different MTU values successfully. This means for example that when the system is rebooted, MTU values of the VLAN interfaces depends on the order in which the interfaces are brough up or added to to bridge. RedHat OpenStack documentation states: "It is recommended that the Provisioning interface, External interface, and any floating IP interfaces be left at the default MTU of 1500." and "The Storage, Storage Management, Internal API, and Tenant networking all benefit from jumbo frames." In general, all VLAN networks can have different MTU values so that each endpoint of a single network has same MTU value configured, as long as that MTU value is not larger than the underlying physical interface MTU. This bug prevents reliable networking implementation and design, or at least forces to implement some post reboot/configuration hacks to fix the MTU values back to the correct ones after the OVS bridges has been created. Related to this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1283312 Version-Release number of selected component (if applicable): osp 7 # ovs-vsctl --version ovs-vsctl (Open vSwitch) 2.4.0 Compiled Mar 22 2016 08:42:47 DB Schema 7.12.1 # uname -rvpio 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55 EST 2016 x86_64 x86_64 GNU/Linux # cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.2 (Maipo) # nova-manage --version 2015.1.3 # openstack --version openstack 1.0.3 How reproducible: Always Steps to Reproduce: Create configuration files for One bridge with two VLANs with different MTUs: # cat ifcfg-test-br DEVICE=test-br ONBOOT=yes HOTPLUG=no NM_CONTROLLED=no DEVICETYPE=ovs TYPE=OVSBridge # cat ifcfg-vlan1500 DEVICE=vlan1500 ONBOOT=yes HOTPLUG=no NM_CONTROLLED=no DEVICETYPE=ovs TYPE=OVSIntPort OVS_BRIDGE=test-br OVS_OPTIONS="tag=1500" MTU=1500 BOOTPROTO=static # cat ifcfg-vlan1600 DEVICE=vlan1600 ONBOOT=yes HOTPLUG=no NM_CONTROLLED=no DEVICETYPE=ovs TYPE=OVSIntPort OVS_BRIDGE=test-br OVS_OPTIONS="tag=1600" MTU=1600 BOOTPROTO=static Create them: # ifup test-br # ifup vlan1500 # ifup vlan1600 MTU values are still correct: # ip l | egrep '(test-br|vlan1(50|55|60)0|ens2f1)' 6: ens2f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000 212: test-br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT 213: vlan1600: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1600 qdisc noqueue state UNKNOWN mode DEFAULT 214: vlan1500: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT Then add physical interface ens2f1 with bigger MTU than any of the VLAN interfaces have to the bridge. a) Either change MTU and add it to the bridge manually: # ip link set ens2f1 mtu 1700 # ovs-vsctl add-port test-br ens2f1 b) Or create config file and bring it down/up: # cat ifcfg-ens2f1 DEVICE="ens2f1" BOOTPROTO=none ONBOOT=yes DEVICETYPE=ovs TYPE=OVSPort OVS_BRIDGE=test-br NM_CONTROLLED=no MTU=1700 # ifdown ens2f1; ifup ens2f1 In both cases (a & b), VLAN MTU values have been changed: # ip l | egrep '(test-br|vlan1(50|55|60)0|ens2f1)' 6: ens2f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1700 qdisc mq master ovs-system state UP mode DEFAULT qlen 1000 212: test-br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1700 qdisc noqueue state UNKNOWN mode DEFAULT 213: vlan1600: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1700 qdisc noqueue state UNKNOWN mode DEFAULT 214: vlan1500: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1700 qdisc noqueue state UNKNOWN mode DEFAULT But adding new VLAN to the bridge will retain it's MTU: # cat ifcfg-vlan1550 DEVICE=vlan1550 ONBOOT=yes HOTPLUG=no NM_CONTROLLED=no DEVICETYPE=ovs TYPE=OVSIntPort OVS_BRIDGE=test-br OVS_OPTIONS="tag=1550" MTU=1550 BOOTPROTO=static # ifup vlan1550 # ip l | egrep '(test-br|vlan1(50|55|60)0|ens2f1)' 6: ens2f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1700 qdisc mq master ovs-system state UP mode DEFAULT qlen 1000 218: test-br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1700 qdisc noqueue state UNKNOWN mode DEFAULT 219: vlan1600: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1700 qdisc noqueue state UNKNOWN mode DEFAULT 220: vlan1500: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1700 qdisc noqueue state UNKNOWN mode DEFAULT 221: vlan1550: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1550 qdisc noqueue state UNKNOWN mode DEFAULT Actual results: if physical interface is added to the same bridge then all VLAN MTU values will be set to the same value as that physical interface has. Expected results: Have VLAN's with differents MTU's Additional info:
I don't think it's relevant for Neutron at all. It sounds more like OVS issue (?). Note that this email thread may be of relevance here: http://openvswitch.org/pipermail/dev/2016-June/073190.html It talks about a different aspect of MTU vs. OVS bridge, but the root cause, I think, is related: ovs bridges do not generally allow to maintain different MTUs on the same switch. It's not clear if it's to be supported by OVS community.
OVS 2.6 will introduce the mtu_request column to Interface table, which allows this setting to apply even after adding the Ethernet interface. Cascardo.
This will only be available after OVS 2.6 is released. Anything you can do to workaround it on Neutron? Cascardo.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.