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] [day] [month] [year] [list]

Message-ID: <56A8F2DA.2030200@cumulusnetworks.com>
Date:	Wed, 27 Jan 2016 08:39:54 -0800
From:	roopa <roopa@...ulusnetworks.com>
To:	Thomas Graf <tgraf@...g.ch>
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 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@...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.
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.