Bug 1685634 - Regression: Neutron OVN does not allow to override global MTU in the config file
Summary: Regression: Neutron OVN does not allow to override global MTU in the config file
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-networking-ovn
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: z12
: 13.0 (Queens)
Assignee: Rodolfo Alonso
QA Contact: Roman Safronov
URL:
Whiteboard:
: 1809344 (view as bug list)
Depends On: 1547074 1702331 1702564
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-05 17:07 UTC by Federico Iezzi
Modified: 2023-09-07 19:50 UTC (History)
13 users (show)

Fixed In Version: python-networking-ovn-4.0.4-3.el7ost
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-24 11:53:05 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 710765 0 None MERGED Propagate mtu to all subnets 2021-02-08 16:55:22 UTC
Red Hat Issue Tracker OSP-28213 0 None None None 2023-09-07 19:50:08 UTC
Red Hat Knowledge Base (Solution) 3138741 0 None None None 2020-02-17 20:30:36 UTC
Red Hat Product Errata RHBA-2020:2724 0 None None None 2020-06-24 11:53:36 UTC

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


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