Bug 1358228 - OVS bridge cannot have internal VLAN interfaces with different MTU values reliably
Summary: OVS bridge cannot have internal VLAN interfaces with different MTU values rel...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openvswitch
Version: 7.0 (Kilo)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: async
: 7.0 (Kilo)
Assignee: Thadeu Lima de Souza Cascardo
QA Contact: Ofer Blaut
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-20 10:13 UTC by Eduard Barrera
Modified: 2019-12-16 06:09 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-20 22:04:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1283312 0 unspecified CLOSED MTU set to 9000 for all VLANs on virtual controllers 2021-02-22 00:41:40 UTC

Description Eduard Barrera 2016-07-20 10:13:26 UTC
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:

Comment 2 Ihar Hrachyshka 2016-07-20 15:08:34 UTC
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.

Comment 5 Thadeu Lima de Souza Cascardo 2016-09-14 19:23:07 UTC
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.

Comment 6 Thadeu Lima de Souza Cascardo 2016-09-20 19:44:16 UTC
This will only be available after OVS 2.6 is released. Anything you can do to workaround it on Neutron?

Cascardo.

Comment 7 RHEL Program Management 2016-09-20 22:04:11 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.


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