From: Stas Sergeev <stsp@list.ru>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: netdev <netdev@vger.kernel.org>,
Sowmini Varadhan <sowmini.varadhan@oracle.com>
Subject: Re: Q: bad routing table cache entries
Date: Tue, 12 Jan 2016 23:43:06 +0300 [thread overview]
Message-ID: <5695655A.60509@list.ru> (raw)
In-Reply-To: <56953C27.4030405@stressinduktion.org>
12.01.2016 20:47, Hannes Frederic Sowa пишет:
> On 12.01.2016 18:33, Stas Sergeev wrote:
>> 12.01.2016 20:26, Hannes Frederic Sowa пишет:
>>> On 12.01.2016 18:18, Stas Sergeev wrote:
>>>> 12.01.2016 20:06, Hannes Frederic Sowa пишет:
>>>>> On 12.01.2016 17:56, Stas Sergeev wrote:
>>>>>> 12.01.2016 19:42, Stas Sergeev пишет:
>>>>>> Also the rfc1620 you pointed, seems to be saying this:
>>>>>>
>>>>>> A Redirect message SHOULD be silently
>>>>>> discarded if the
>>>>>> new router address it specifies is not on the
>>>>>> same
>>>>>> connected (sub-) net through which the
>>>>>> Redirect arrived,
>>>>>> or if the source of the Redirect is not the
>>>>>> current
>>>>>> first-hop router for the specified destination.
>>>>>>
>>>>>> It seems, this is exactly the rule we were trying to find
>>>>>> during the thread. And it seems violated, either. Unless I am
>>>>>> mis-interpreting it, of course.
>>>>>
>>>>> If you read on you will read that with shared_media this exact
>>>>> clause (the first of those) is not in effect any more.
>>>> OK. But how to get such a redirect to work, if (checked with
>>>> tcpdump) the packets do not even go to eth0, but to "lo"?
>>>
>>> I don't know, the router must be on the same shared medium. I guess
>>> physical reconfiguration is required?
>> It is same.
>> Router 192.168.8.1 has just one ethernet port.
>> And even on the 192.168.10.202 node I can do:
>> # arp -a |grep "0.1"
>> ? (192.168.0.1) at 14:d6:4d:1c:97:3d [ether] on eth0
>> So even 0.1 is about to be reachable.
>> Still nothing works.
>> Should it work if 192.168.0.1 router, to which 8.1 redirects,
>> has shared_media disabled?
>
> Can you check with tcpdump?
That's what I already did.
I monitored on 8.1 router and on the node itself,
and my conclusion was that the packets do not
even reach the eth0 interface. Instead I captured
them on "lo" interface, so I assumed such route is
completely broken.
If it is not - how can I even see that it exist? How to
list these redirect routes?
I'd like to do some investigations, but this looks no
more than a black magic without a proper support
from tools, proper documentation, etc.
And I suspect that shared_media is disabled on a 0.1
router, so I wonder if this can work at all, even if the node
is cured to do the right thing with those redirects.
In a nearby message David Miller says:
---
2) increasing the chance of successful communication with peers
---
If this can't work right when one of the gateways has
shared_media disabled, then this rule is clearly violated.
> ping requires the router to also find a correct way back, so packet
> can get stuck at a lot of places. Also uRPF is maybe active which kind
> of defeats shared_media and please check netfilter.
I am pretty sure the node has a default ubuntu without
any special network tweaks, but I'll double-check.
next prev parent reply other threads:[~2016-01-12 20:43 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-29 10:54 Q: bad routing table cache entries Stas Sergeev
2015-12-29 11:58 ` Sowmini Varadhan
2015-12-29 12:06 ` Stas Sergeev
2015-12-29 12:32 ` Sowmini Varadhan
2015-12-29 12:43 ` Stas Sergeev
2015-12-29 13:19 ` Stas Sergeev
2015-12-29 15:22 ` Sowmini Varadhan
2015-12-29 15:38 ` Stas Sergeev
2015-12-29 17:40 ` Stas Sergeev
2015-12-30 12:42 ` Stas Sergeev
2015-12-30 14:17 ` Eric Dumazet
2015-12-30 17:56 ` David Miller
2016-01-04 1:05 ` Sowmini Varadhan
2016-01-04 1:32 ` Stas Sergeev
2016-01-04 17:23 ` Stas Sergeev
2016-01-12 14:40 ` Stas Sergeev
2016-01-12 14:47 ` Sowmini Varadhan
2016-01-12 20:33 ` David Miller
2016-01-12 15:34 ` Hannes Frederic Sowa
2016-01-12 15:52 ` Hannes Frederic Sowa
2016-01-12 16:03 ` Stas Sergeev
2016-01-12 16:10 ` Hannes Frederic Sowa
2016-01-12 16:42 ` Stas Sergeev
2016-01-12 16:56 ` Stas Sergeev
2016-01-12 17:06 ` Hannes Frederic Sowa
2016-01-12 17:18 ` Stas Sergeev
2016-01-12 17:26 ` Hannes Frederic Sowa
2016-01-12 17:33 ` Stas Sergeev
2016-01-12 17:47 ` Hannes Frederic Sowa
2016-01-12 20:43 ` Stas Sergeev [this message]
2016-01-12 22:26 ` Hannes Frederic Sowa
2016-01-12 22:57 ` Stas Sergeev
2016-01-12 23:07 ` Hannes Frederic Sowa
2016-01-13 12:59 ` Stas Sergeev
2016-01-12 17:41 ` Stas Sergeev
2016-01-12 15:57 ` Stas Sergeev
-- strict thread matches above, loose matches on Subject: below --
2015-12-28 15:26 Stas Sergeev
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=5695655A.60509@list.ru \
--to=stsp@list.ru \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.org \
--cc=sowmini.varadhan@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.