Date:	Wed, 13 Jan 2016 00:07:54 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	netdev <netdev@...r.kernel.org>,
	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Subject: Re: Q: bad routing table cache entries

Hi,

On 12.01.2016 23:57, Stas Sergeev wrote:
> 13.01.2016 01:26, Hannes Frederic Sowa пишет:
>> I didn't check a full featured setup but just did some dirty testing
>> with namespaces and I had correct arp request for the now to be
>> assumed on-link router on the external veth.
> I haven't checked anything with arp.
> I set up tcpdump to only capture icmp.
> What would you like me to check, could you please
> give the detailed instructions?

Check simply for arp traffic on the interface. arp requests should leave 
your client and ask directly for the new router you got as next-hop. If 
it does not answer, there is the problem.

>>> If it is not - how can I even see that it exist? How to
>>> list these redirect routes?
>>
>> Yeah, that might be a minor issue. The rt_cache procfs files are empty
>> since the deletion of the cache and we probably don't have an
>> interface for next hop exceptions, I consider this todo. :) ip route
>> get is your only hope right now.
>>
>> Anyway, seems like there are problems with redirect timeout somehow. I
>> am investigating this.
>>
>>> 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.
>>
>> Hmm, so far I think shared_media is behaving like it should,
> No, unless you correct the documentation:
> https://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/theconfvariables.html
>
> It says not what you say.
> So this feature is essentially poorly (or wrongly) documented.

I am sorry, but I have no access to this website. I just grepped around 
in the Documentation/ directory of the kernel:
<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/ip-sysctl.txt?id=refs/tags/v4.4#n1014>

It is correctly documented there and also references the RFC. I think 
this is fine. Please feel free to send a patch, it will be welcomed.

>> besides maybe it shouldn't be the default setting. Maybe someone who
>> can remember why it is default could chime in?
>>
>>> 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:
>>
>> Default is that shared_media is enabled,
> On what OS, and since what version?
>
>> so the chances are relatively high that it is enabled if it is not
>> turned off.
> I don't even know what is there in a 0.1 router - maybe windows95,
> who knows. You can't assume the latest linux kernel is everywhere.

Looking into the kernel cvs history the change was done in 2000(!). 
Would be pretty strange to find such an old kernel there.

>>> ---
>>>
>>> 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.
>>
>> It can work right and I think the RFC actually gives examples where it
>> is very useful. Also IPv6 adapts it as the default, so it might make
>> sense to have it as default.
>>
>> I still consider something broken in your network setup, maybe.
>>
>>>> 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.
>>
>> Please do that. Thanks!
> OK but please make it clear what should I check.
> iptables do not seem to be in the game, what else to check?

Please have a look for arp traffic as written before.

Thanks,
Hannes

Powered by blists - more mailing lists