netdev - Re: [ovs-dev] [PATCH net 1/2] vxlan: Relax the MTU constraint on vxlan devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160110102836.GD1190@pox.localdomain>
Date:	Sun, 10 Jan 2016 11:28:36 +0100
From:	Thomas Graf <tgraf@...g.ch>
To:	roopa <roopa@...ulusnetworks.com>
Cc:	David Wragg <david@...ve.works>, dev@...nvswitch.org,
	netdev@...r.kernel.org
Subject: Re: [ovs-dev] [PATCH net 1/2] vxlan: Relax the MTU constraint on
 vxlan devices

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@...ve.works>
> >
> Acked-by: Roopa Prabhu <roopa@...ulusnetworks.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.