RDO tickets are now tracked in Jira https://issues.redhat.com/projects/RDO/issues/
Bug 1160897 - Openvswitch ignoring the MTU set in the bridge configuration file
Summary: Openvswitch ignoring the MTU set in the bridge configuration file
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: RDO
Classification: Community
Component: openvswitch
Version: unspecified
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: Juno
Assignee: Flavio Leitner
QA Contact: Ofer Blaut
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-05 22:56 UTC by Alex Dodson
Modified: 2019-10-23 03:11 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-12-15 13:23:46 UTC
Embargoed:


Attachments (Terms of Use)

Description Alex Dodson 2014-11-05 22:56:16 UTC
Description of problem: Openvswitch does not honour the MTU set in the bridge configuration file which causes issues when using VLANS


Version-Release number of selected component (if applicable):
Openvswitch Version     : 2.1.2 Release     : 1.el6


How reproducible:

Set MTU of 9000 in ifcfg-br-* like below

DEVICE=br-eth0
BOOTPROTO=none
FIREWALL_MODS=no
USERCTL=no
PEERDNS=no
ONBOOT=yes
TYPE=OVSBridge
DEVICETYPE=ovs
MTU=9000
IPADDR=xxx.xxx.xxx.xxx
NETMASK=255.255.255.0
GATEWAY=xxx.xxx.xxx.xxx
IPV6INIT=yes
NM_CONTROLLED=no


Steps to Reproduce:
1. Bring up network with openvswitch
2.
3.

Actual results:
It sets the MTU to the same as the MTU you have set in ifcfg-eth0

Expected results:
It should bring up the interface at 9000 like specified in the configuration

Additional info:
To work around this I have to edit ifup-ovs to check for the mtu and set it appropriately. 


 if [ -n "${MTU}" ]; then
     ip link set dev ${DEVICE} mtu ${MTU}
 fi

When openvswitch updates it breaks networking on all my nodes as it overwrites the modified ifup-ovs script. Having ovs check the configuration file for an MTU and applying it would be ideal.

Comment 1 Alex Dodson 2014-11-06 01:37:21 UTC
I should mention this is for openstack icehouse. I am not sure whether it impacts juno or not.

Comment 3 Alex Dodson 2014-11-06 23:44:25 UTC
Hi,

This occurs regardless of neutron or not. It is openvswitch ignoring the MTU set in ifcfg-br-eth0 and setting the MTU from ifcfg-eth0. To fix this I added the mtu check mentioned above to make ifup-ovs check for MTU in the bridge it brings up and set the value there if it is present.

By default I have eth0 set to 9192 and br-eth0 set to 9000. The behavior of the current openvswitch unmodified ignores the setting of 9000 in br-eth0 and brings the br-eth0 up with 9192. 

We don't use neutron layer 3 agent or gre tunneling. Routing is done by hardware not a software router in Openstack.

Here are the interface settings for one compute node if they will help make it clearer.

DEVICE=eth0
BOOTPROTO=none
FIREWALL_MODS=no
USERCTL=no
PEERDNS=no
ONBOOT=yes
TYPE=OVSPort
DEVICETYPE=ovs
MTU=9192
HWADDR=00:25:90:e6:df:fb
IPV6INIT=yes
IPV6_AUTOCONF=no
OVS_BRIDGE=br-eth0


DEVICE=br-eth0
BOOTPROTO=none
FIREWALL_MODS=no
USERCTL=no
PEERDNS=no
ONBOOT=yes
TYPE=OVSBridge
DEVICETYPE=ovs
MTU=9000
IPADDR=xxx.xxx.xxx.xxx
NETMASK=255.255.255.0
GATEWAY=xxx.xxx.xxx.xxx
IPV6INIT=yes
NM_CONTROLLED=no

Comment 4 Flavio Leitner 2014-11-07 19:07:35 UTC
> Actual results:
> It sets the MTU to the same as the MTU you have set in ifcfg-eth0

That is expected. All interfaces in the same L2 broadcast domain must have the same MTU. So, the MTU on OVS bridge is being set, but when you put another different one in the OVS port, the bridge adjusts itself.

I believe the same would happen with Linux bridge.

Comment 5 Rashid Khan 2014-11-24 14:40:14 UTC
Hi Alex
Any updates ? 
Have not heard from you in about ~3 weeks

Comment 6 Rashid Khan 2014-12-01 14:31:22 UTC
Hi Alex, 
Can you please reply to Flavio's comment above. 
Thanks

Comment 7 Flavio Leitner 2014-12-15 13:23:46 UTC
I am closing this bug due to inactivity and because it doesn't look like a bug to me.

Please feel free to re-open if you think otherwise.
fbl


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