[OVN] Lacking mechanism to provide proper MTU to instances

[Matt Kassawara]

Virtual networks using an overlay protocol such as GENEVE include overhead that reduces the effective MTU for an instance. By default, network interfaces in an instance use a 1500 MTU. If the physical network also uses a 1500 MTU, an instance cannot send a packet using a 1500 MTU due to overlay protocol overhead. Neutron offers a net-mtu extension that provides a field indicating MTU for a particular network. In the ML2 plug-in, this value accounts for the amount of overhead via type driver. The DHCP agent can provide this value to instances. The OVN plug-in needs a mechanism for indicating a proper MTU value that accounts for any overlay protocol overhead. Similar to ML2, the conventional DHCP agent can provide this value, but OVN also needs to consider the implications with a native DHCP agent.

[Russell Bryant (russellb)]

You added support for the "net-mtu" extension. What work items remain?

[Matt Kassawara (ionosphere80)]

At a minimum, implement a way to provide a MTU value that accounts for any overlay network overhead to instances via DHCP, RA, etc. Additional development requires routing between different network types (e.g., provider and private) so we can test MTU disparities between them.

[Matt Kassawara (ionosphere80)]

Until we can sufficiently test routing between provider and private networks, we can at least implement the following:

1) Configure the 'global_physnet_mtu' option in neutron.conf to indicate the MTU of the underlying physical network.
2) For provider networks, populate the 'mtu' network parameter with the value of 'global_physnet_mtu' because these networks do not use an overlay protocol that adds overhead. Provide this MTU value to instances via DHCP or RA.
3) For private networks, subtract the overlay protocol overhead from the value of 'global_physnet_mtu' and populate the 'mtu' network parameter with this value. Provide this MTU value to instances via DHCP or RA.

[Han Zhou (zhouhan)]

This sounds good, but is there a way to make it work when static IP is used (means no DHCP)?

[Russell Bryant (russellb)]

sounds like something that should be exposed through network info in config drive / metadata API

[Matt Kassawara (ionosphere80)]

You can currently retrieve the MTU via API which means your instance has access to it via metadata regardless of DHCP/RA.

[Thiago Martins (martinx)]

I have Networking OVN up and running, it is awesome!

Now, I need jumbo frames... Not working.

The underlying data path (where GENEVE in running on), is configured correctly, I can test it with:

ping -M do -s 8500 $DEST

Where $DEST is the other(s) Compute Node(s).

So, from a Compute Node to the others, jumbo frames is enabled.

Neutron and ML2 are configured to 9000.

The Instances received its MTU from OVN DHCP = 8942, but, from an Instance, I can't use jumbo frames to "ping" other Instances!

I can see that both "br-int" and the Instance's "tapXXX" interfaces are still with MTU=1500.

Is this the problem?

If yes, is there any workaround?

[Lucas Alvares Gomes (lucasagomes)]

The OVN driver now lives in the neutron repository. Moving this bug to their tracker.