netdev - Re: [PATCH net-next 1/3] udp_tunnel: allow to turn off path mtu discovery on encap sockets

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: <a6821eac-82f8-0d9e-6388-ea6c9f5535d1@gmail.com>
Date:   Mon, 13 Jul 2020 08:41:52 -0600
From:   David Ahern <dsahern@...il.com>
To:     Florian Westphal <fw@...len.de>
Cc:     Stefano Brivio <sbrivio@...hat.com>, netdev@...r.kernel.org,
        aconole@...hat.com
Subject: Re: [PATCH net-next 1/3] udp_tunnel: allow to turn off path mtu
 discovery on encap sockets

On 7/13/20 8:02 AM, Florian Westphal wrote:
> David Ahern <dsahern@...il.com> wrote:
>> On 7/13/20 2:04 AM, Florian Westphal wrote:
>>>> As PMTU discovery happens, we have a route exception on the lower
>>>> layer for the given path, and we know that VXLAN will use that path,
>>>> so we also know there's no point in having a higher MTU on the VXLAN
>>>> device, it's really the maximum packet size we can use.
>>> No, in the setup that prompted this series the route exception is wrong.
>>
>> Why is the exception wrong and why can't the exception code be fixed to
>> include tunnel headers?
> 
> I don't know.  This occurs in a 3rd party (read: "cloud") environment.
> After some days, tcp connections on the overlay network hang.
> 
> Flushing the route exception in the namespace of the vxlan interface makes
> the traffic flow again, i.e. if the vxlan tunnel would just use the
> physical devices MTU things would be fine.
> 
> I don't know what you mean by 'fix exception code to include tunnel
> headers'.  Can you elaborate?

lwtunnel has lwtunnel_headroom which allows ipv4_mtu to accommodate the
space needed for the encap header. Can something similar be adapted for
the device based tunnels?

> 
> AFAICS everyhing functions as designed, except:
> 1. The route exception should not exist in first place in this case
> 2. The route exception never times out (gets refreshed every time
>    tunnel tries to send a mtu-sized packet).
> 3. The original sender never learns about the pmtu event

meaning the VM / container? ie., this is a VPC using VxLAN in the host
to send packets to another hypervisor. If that is the case why isn't the
underlay MTU bumped to handle the encap header, or the VMs MTU lowered
to handle the encap header? seems like a config problem.