[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-discuss
Subject:    [ovs-discuss] MTU considerations for OVN
From:       mkassawara () gmail ! com (Matt Kassawara)
Date:       2016-01-28 1:02:58
Message-ID: CABA+jQocvgHJb6RaRy9aX3GAVcgOnny4X_rakFJ2AfbSLmJZ+A () mail ! gmail ! com
[Download RAW message or body]

Hi,

Conventional OpenStack Networking service (neutron) drivers such as Open
vSwitch and Linux bridge have a long history of MTU issues involving
overlay networks. For example, consider the following typical virtual
network architecture:

1) A provider network using native Ethernet or 802.1q tagging connects the
physical and virtual network infrastructure. Typically uses a 1500 or 9000
MTU.
2) A private network using an overlay such as VXLAN or GRE. Overlay
protocol overhead reduces the effective MTU available to a VM.
3) A VM attaching to the private network.
4) A virtual router connecting the provider and private networks.

For a packet outbound from a VM, we can simply set the MTU of the network
interface in the VM to account for overlay protocol overhead. For example,
if the underlying network supports a 1500 MTU, a VM attaching to a VXLAN
overlay network should use a 1450 MTU. We can provide this MTU to the VM
via DHCP, RA, or manual configuration of the interface.

For a packet inbound to a VM, the situation becomes more interesting. The
host sending the packet usually resides outside of the overlay network and
attempts to use the MTU available to it, typically 1500 or greater. The
provider network also uses a 1500 MTU. The virtual router contains
interfaces on the provider network using a 1500 MTU and the private network
using a 1450 MTU. As the packet attempts to traverse the router, it hits
the MTU disparity between 1500 and 1450 which causes the provider interface
to originate an ICMP message for PMTU discovery containing the 1450 MTU.
The host receives this message and sends the packet again using the 1450
MTU.

Currently, both the Open vSwitch and Linux bridge drivers incorrectly place
MTU disparities in layer-2 components which cannot originate ICMP messages
and drop packets that exceed the MTU.

Using the native layer-3 implementation, how does OVN handle MTU
disparities between provider networks and private networks using an overlay
protocol?

Thanks,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/discuss/attachments/20160127/4cdc8581/attachment.html>

[prev in list] [next in list] [prev in thread] [next in thread]