neutron

[OVN] Lacking mechanism to provide proper MTU to instances

Bug #1542503 reported by Matt Kassawara
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
neutron
New
Undecided
Unassigned

Bug Description

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.

Tags: ovn
Revision history for this message
Russell Bryant (russellb) wrote :

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

Changed in networking-ovn:
status: New → Incomplete
Revision history for this message
Matt Kassawara (ionosphere80) wrote :

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.

Russell Bryant (russellb)
Changed in networking-ovn:
status: Incomplete → Confirmed
importance: Undecided → Medium
status: Confirmed → In Progress
assignee: nobody → Matt Kassawara (ionosphere80)
Revision history for this message
Matt Kassawara (ionosphere80) wrote :

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.

Changed in networking-ovn:
assignee: Matt Kassawara (ionosphere80) → nobody
status: In Progress → Confirmed
Revision history for this message
Han Zhou (zhouhan) wrote :

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

Revision history for this message
Russell Bryant (russellb) wrote :

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

Revision history for this message
Matt Kassawara (ionosphere80) wrote :

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

Revision history for this message
Thiago Martins (martinx) wrote :

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?

Revision history for this message
Lucas Alvares Gomes (lucasagomes) wrote :

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

tags: added: ovn
summary: - Lacking mechanism to provide proper MTU to instances
+ [OVN] Lacking mechanism to provide proper MTU to instances
no longer affects: networking-ovn
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.