From: Michael Tokarev <mjt@tls•msk.ru>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: netdev <netdev@vger•kernel.org>, David Miller <davem@davemloft•net>
Subject: Re: 3.0: unexpected route cache entry for wrong segment?
Date: Wed, 15 Feb 2012 16:10:37 +0400 [thread overview]
Message-ID: <4F3BA0BD.9010501@msgid.tls.msk.ru> (raw)
In-Reply-To: <4F341283.1020904@msgid.tls.msk.ru>
On 09.02.2012 22:37, Michael Tokarev wrote:
> On 09.02.2012 21:45, Eric Dumazet wrote:
[]
>> Did you try to apply by hand commits :
>>
>> 7cc9150ebe8ec06cafea9f1c10d92ddacf88d8ae // added in 3.2
>> (route: fix ICMP redirect validation)
>>
>> and
>> 9cc20b268a5a14f5e57b8ad405a83513ab0d78dc
>> (ipv4: fix redirect handling)
>
> I haven't tried anything yet, as mentioned above: this prob
> just appeared today, out of the sudden, and what's the most
> important (imho) is that I can not reproduce it. The host
> hasn't been rebooted, I were thinking about maybe some
> experiments with it before doing anything else.
>
> But I blocked this specific IP address on the gateway and the
> cached entry expired after 10 minutes (that host tried to
> check mail every minute so no doubt the inactivity timer
> never triggered). So at least one difference in behavour is
> now gone.
>
> What bothers me more are 3 other issues I see around this:
>
> 1. Why this specific IP were cached to start with? I don't
> expect any ICMP redirects for that network at all, and no
> spoofing or malicious traffic either.
>
> 2. I can't reproduce the issue while forcing ICMP redirects.
> Maybe my original prob was not due to a redirect but due to
> something else? I dunno.
>
> 3. Why it affects whole host and all numerous different/separate
> network namespaces on it? _All_ lxc containers started thinking
> this IP is reachable on the local subnet, at once, even those
> who never ever tried to send any packets to that IP before!
Do you have any insight about all this? That smells.. fishy
somehow. Or maybe not, since all lxc guests here are connected
to the same bridge on the host, so it is the host who does the
bad thing, apparently, hence affecting all the guests (guest
routes packets over veth to host which does further bridging/routing).
> And in another email you wrote:
>
>> David is currently working on backporting to 3.0 all necessary fixes for
>> this exact problem.
David, any progress with these?
7cc9150ebe8ec06cafea9f1c10d92ddacf88d8ae "route: fix ICMP redirect validation"
applies correctly to 3.0, but 9cc20b268a5a14f5e57b8ad405a83513ab0d78dc
"ipv4: fix redirect handling" does not, due to some changes in-between,
but these should be easy to sort out. Should I perhaps refresh this
patch myself? It should be doable, I think.
Thank you!
/mjt
next prev parent reply other threads:[~2012-02-15 12:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-09 17:02 3.0: unexpected route cache entry for wrong segment? Michael Tokarev
2012-02-09 17:45 ` Eric Dumazet
2012-02-09 18:05 ` Eric Dumazet
2012-02-09 18:37 ` Michael Tokarev
2012-02-15 12:10 ` Michael Tokarev [this message]
2012-02-15 12:44 ` Michael Tokarev
2012-02-15 12:46 ` Eric Dumazet
2012-02-15 12:57 ` Michael Tokarev
2012-02-15 13:03 ` Eric Dumazet
2012-02-28 11:38 ` Michael Tokarev
2012-02-28 19:07 ` David Miller
2012-02-29 1:00 ` Michael Tokarev
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F3BA0BD.9010501@msgid.tls.msk.ru \
--to=mjt@tls$(echo .)msk.ru \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox