Bug 1685634

Summary:	Regression: Neutron OVN does not allow to override global MTU in the config file
Product:	Red Hat OpenStack	Reporter:	Federico Iezzi <fiezzi>
Component:	python-networking-ovn	Assignee:	Rodolfo Alonso <ralonsoh>
Status:	CLOSED ERRATA	QA Contact:	Roman Safronov <rsafrono>
Severity:	high	Docs Contact:
Priority:	high
Version:	13.0 (Queens)	CC:	agoossen, amuller, apevec, chrisbro, jlibosva, lhh, lmartins, majopela, mgarciac, pveiga, ralonsoh, scohen, slinaber
Target Milestone:	z12	Keywords:	Triaged, ZStream
Target Release:	13.0 (Queens)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	python-networking-ovn-4.0.4-3.el7ost	Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-06-24 11:53:05 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:
Embargoed:
Bug Depends On:	1547074, 1702331, 1702564
Bug Blocks:

Description Federico Iezzi 2019-03-05 17:07:45 UTC

Description of problem:
Neutron ML2/OVS has the ability to define a global MTU and also to override it in every bridge mapping.
In TripleO this is implemented as follows
- NeutronGlobalPhysnetMtu (neutron::global_physnet_mtu)
- NeutronML2PhysicalNetworkMtus (neutron::plugins::ml2::physical_network_mtus)

The NeutronML2PhysicalNetworkMtus is especially useful for any operators using provider networks with a different MTU than the global one.
Any operator using OVN will have 58 Bytes for the outer headers and Geneve encapsulation. So in order to have an overlay tenant networks with standard 1500 Bytes MTU, NeutronGlobalPhysnetMtu needs to be set at 1558.
Due to OVN, at this point, it's not possible to globally override provider networks MTU size. So any provider network will have a weird mtu of 1558 bytes.

The only workaround available is to create those specifying the desired MTU size.
This introduces a change in the network creation workflow which for some operation could be a hard blocker adopting OVN.

Version-Release number of selected component (if applicable):
OSP13, OSP14, OSP15

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 7 Jakub Libosvar 2020-03-03 14:28:17 UTC

*** Bug 1809344 has been marked as a duplicate of this bug. ***

Comment 30 Roman Safronov 2020-06-03 18:50:43 UTC

Verified on   13.0-RHEL-7/2020-05-28.2 with   python-networking-ovn-4.0.4-6.el7ost.noarch.

Tested on a virt environment with 9000 bytes MTU on bridges and all nodes interfaces.
Configured the following settings:
global_physnet_mtu=9000   in neutron.conf on all controllers
path_mtu=1558 in ml2 section of ml2_conf.ini
Note: I did not set physical_network_mtus because it needed for the case if we want to override global_physnet_mtu with a value that differs from global_physnet_mtu (it was tested in comment 17 and found working for provider network)
Configured vlan 11 on the external bridge and also datacentre network to be vlan and no flat.

Created vlan provider network as follows:
Command: openstack network create  --provider-physical-network datacentre --provider-network-type vlan --provider-segment 11 --external public
Result: network with mtu 9000 was created

Created tenant network (without specifying --mtu):
Command: openstack network create internal_A
Result: network with mtu 1500 created 

Performed also some sanity testing, created router, connected networks to the router, launched an instance, verified that the instance is accessible.

Comment 34 errata-xmlrpc 2020-06-24 11:53:05 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:2724