On 01/09/16 at 10:39am, roopa wrote: > On 1/6/16, 5:33 AM, David Wragg wrote: > > Allow the MTU of vxlan devices without an underlying device to be set to > > larger values (up to a maximum based on IP packet limits and vxlan > > overhead). > > > > Previously, their MTUs could not be set to higher than the conventional > > ethernet value of 1500. This is a very arbitrary value in the context > > of vxlan, and prevented such vxlan devices from being able to take > > advantage of jumbo frames etc. > > > > The default MTU remains 1500, for compatibility. > > > > Signed-off-by: David Wragg <david@weave.works> > > > Acked-by: Roopa Prabhu <ro...@cumulusnetworks.com> > > I have an internal patch which does the same thing and > was hoping to post it soon. > I am not using ovs. so, I am not closely following the thread on the other > patch in the series. But, this patch certainly stands on its own and is > required.
Agreed. In fact the issue described is not OVS specific, anyone using a tunnel device in metadata mode benefits form this but is also exposed to the MTU issue. We either create a tunnel device for each underlay device and thus expose the baremetal MTU into the virtual network thus allowing for the L3 in the virtual network to check the MTU or we will not notice until we hit the underlay in which the context for the ICMP is much less useful. I'll think about how to solve this as discussed in the other portion of this thread as I assume you will be interested in a fix for this as well. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
