netdev - Re: [PATCH net v2] net: lwtunnel: handle MTU calculation in forwading

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]

Date:   Mon, 28 Jun 2021 12:45:02 -0600
From:   David Ahern <dsahern@...il.com>
To:     Vadim Fedorenko <vfedorenko@...ek.ru>,
        David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org,
        Roopa Prabhu <roopa@...dia.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net v2] net: lwtunnel: handle MTU calculation in forwading

On 6/26/21 3:41 PM, Vadim Fedorenko wrote:
>>
>> I think this is the right approach - tunnel overhead should always be
>> considered for the mtu. Did you run the pmtu.sh selftests to make sure
>> those still work?
>>
> 
> Actually not, I was running my own tests of routing configurations with
> different types of tunnels like GRE, GUE and FOU with mpls lwtunnels to
> check consistency of calculated mtus.
> 
> Will re-run pmtu.sh but I my installation doesn't support OVS right now.
> 
> Also, I was thinking about this RTAX_MTU and I'm really in doubt. Do we
> actually want the situation when
>   ip route A.B.C.D/32 encap mpls 100 dev ip6tnl1 mtu 1400
> will actually require mtu=1396? Because this looks like not clear for
> users I suppose.

It is simpler and cleaner to me for the stack to always subtract known
tunnel overhead from the MTU and not expect users to do the math which
is why I responded as this is the right approach.