netdev - Re: [PATCH net] net: ipv4: fix path MTU for multi path routes

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 for Android: free password hash cracker in your pocket

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

Message-ID: <dc6aafb6-cd1f-2006-6f45-55a4f224e319@gmail.com>
Date:   Sun, 1 Aug 2021 11:12:00 -0600
From:   David Ahern <dsahern@...il.com>
To:     Vadim Fedorenko <vfedorenko@...ek.ru>
Cc:     Willem de Bruijn <willemb@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net] net: ipv4: fix path MTU for multi path routes

On 7/30/21 7:17 PM, Vadim Fedorenko wrote:
> Bug 213729 showed that MTU check could be used against route that
> will not be used in actual transmit if source ip is not specified.
> But path MTU update is always done on route with defined source ip.
> Fix route selection by updating flow info in case when source ip
> is not explicitly defined in raw and udp sockets.
> 
>

There is more to it than just setting the source address and doing a
second lookup.

Attached is a test script I started last summer which shows the problem
at hand and is setup to cover various permutations of routing (legacy
routing, nexthop objects, and vrf), network protocols (v4 and v6) and
should cover tcp, udp and icmp:

# PMTU handling with multipath routing.
#
#          .-- sw1 --.
#   h1 ----|-- sw2 --|---- h2 -------- h3
#          |   ...   |       reduced mtu
#          .-- swN --.
#
# h2-h3 segment has reduced mtu.
# Exceptions created in h1 for h3.

N=8 (8-way multipath) seems to always demonstrate it; N=2 is a 50-50 chance.

Snippet from a run this morning:

# ip netns exec h1 ping -s 1450 10.100.2.254
PING 10.100.2.254 (10.100.2.254) 1450(1478) bytes of data.
>From 10.2.22.254 icmp_seq=1 Frag needed and DF set (mtu = 1420)
>From 10.2.22.254 icmp_seq=2 Frag needed and DF set (mtu = 1420)
>From 10.2.22.254 icmp_seq=3 Frag needed and DF set (mtu = 1420)
>From 10.2.22.254 icmp_seq=4 Frag needed and DF set (mtu = 1420)

ok, an MTU message makes it back to h1, but that it continues shows the
exception is not created on the right interface:

# ip -netns h1 ro ls cache
10.100.2.254 via 10.1.15.5 dev eth5
    cache expires 580sec mtu 1420

But the selected path is:
# ip -netns h1 ro get 10.100.2.254
10.100.2.254 via 10.1.12.2 dev eth2 src 10.1.12.254 uid 0
    cache

Adding in the source address does not fix it but it does change the
selected path. .e.g,

# ip -netns h1 ro get 10.100.2.254 from 10.1.16.254
10.100.2.254 from 10.1.16.254 via 10.1.14.4 dev eth4 uid 0
    cache

If 10.1.16.254 is the set source address then egress should be eth6, not
eth4, since that is an address on eth6.

Download attachment "pmtu-mpath.sh" of type "application/x-sh" (9536 bytes)