Netdev Archive on
help / color / mirror / Atom feed
From: David Ahern <>
To: Vadim Fedorenko <>
Cc: Willem de Bruijn <>,
	Paolo Abeni <>, Jakub Kicinski <>,
	"David S. Miller" <>,
Subject: Re: [PATCH net] net: ipv4: fix path MTU for multi path routes
Date: Thu, 5 Aug 2021 17:13:08 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 8/5/21 2:51 PM, Vadim Fedorenko wrote:
> On 01.08.2021 18:12, David Ahern wrote:
>> 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.
> You are right. Update of source address fixes only some specific cases.
> Also, I'm not fun of doing several lookups just because we found additional
> next hops. It looks like (for ipv4 case) fib_table_lookup() should select
> correct next-hop based on hash and update source ip and output interface
> for flowi4. But right now flowi4 is constant and such change looks more
> like net-next improvement. Or do you have another solution?

This is a rare case where I wrote the test script first lacking ideas at
that moment. What comes to mind now is that one part of the solution is
to make ipv4 similar to ipv6 in that

1. device bind is always stronger than source address bind, and
2. if saddr is set, prefer the nexthop device with that address (but
only for local traffic). This handles the connect() case where saddr has
not been set yet.

The second one will get expensive if a device has multiple addresses.
FIB lookups for IPv4 have been highly optimized, and we do not want to
explode the lookup time for forwards where saddr is always known and it
does not need to be considered in the lookup to fix local local traffic
which needs a saddr to be picked along with the egress device. Perhaps a
flow flag (SKIP_SADDR similar to the current SKIP_NH_OIF) will address
this part. Another less desirable option is to improve but not totally
fix the problem by only considering the primary address.

For ICMP the PMTU update should look at the header returned in the icmp
payload to determine which device needs the pmtu exception.

      reply	other threads:[~2021-08-05 23:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-31  1:17 Vadim Fedorenko
2021-08-01 17:12 ` David Ahern
2021-08-05 20:51   ` Vadim Fedorenko
2021-08-05 23:13     ` David Ahern [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH net] net: ipv4: fix path MTU for multi path routes' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).