On 1/10/16, 2:28 AM, Thomas Graf wrote: > 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. thanks thomas, will watch the thread. for now I need this for the vxlan netdevice on my vxlan gateway. I don't really configure a default dst.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
