Hi Eric,
On Wed, Sep 30, 2015 at 1:42 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> On Wed, 2015-09-30 at 13:10 -0300, Hugo Vasconcelos Saldanha wrote:
>> Hi,
>>
>> While updating the kernel from v3.2 to v3.14, I started to see a
>> different behavior concerning ICMP redirects sent by this updated
>> server. The network is somewhat configured like this:
>>
>> ---|firewall|----{Internet}
>> |client|------|
>> |
>> ---|router|------|172.16/12 network|
>>
>> The client's default gateway is 'firewall', which is the updated
>> server. It has a static route to 172.16 network by 'router'. If
>> 'client' wants to talk to a server in that network, 'firewall' sends a
>> ICMP redirect pointing to router as the gateway.
>>
>> This worked fine with v3.2. But after the upgrade, if an ICMP message
>> that is rate-limited (by the sysctl_icmp_ratelimit mask) is sent to
>> 'client', ICMP redirects stop being sent to the same client. This
>> happens, for example, when traceroute'ing from the client to the
>> server inside the mentioned network. In this situation, a ICMP Time
>> Exceeded message is sent in response to traceroute's first packet, but
>> then the following packets never generate any ICMP redirect messages
>> in 'firewall'.
>>
>> Debugging the code, I was able to see that the problem is being caused
>> by the fact that ip_rt_send_redirect() started to use the inetpeer
>> cache and the fields used to rate limit ICMP redirects (rate_tokens
>> and rate_last) are now being shared with the algorithm applied in
>> inet_peer_xrlim_allow(). This never happened with v3.2 because
>> apparently inet_peer_xrlim_allow() and ip_rt_send_redirect() used
>> different inetpeer objects.
>>
>> The reason why this breaks the functionality is that, while
>> inet_peer_xrlim_allow() uses a time bucket, ip_rt_send_redirect() uses
>> rate_tokens as a packet counter. Not to mention the fact that these
>> are two completely different policies which should be controlled by
>> different buckets, counters, flags, etc. Because of this,
>> ip_rt_redirect_silence, ip_rt_redirect_number and ip_rt_redirect_load
>> /proc files are broken also.
>>
>> The easiest solution would be to create new fields in 'struct
>> inetpeer' to control ICMP redirects only, but I'm not able to measure
>> its convenience.
>>
>> Any thoughts?
>>
>> PS: Apparently, a similar problem was reported here:
>> http://marc.info/?l=linux-netdev&m=139696540600985
>>
>> PS2: I could try to reproduce the problem with the latest code if this
>> is really necessary.
>
> Hmm... Do you have commit
>
> 4cdf507d54525842dfd9f6313fdafba039084046
> ("icmp: add a global rate limitation")
> in your kernel ?
>
No, but i just tested it and problem continues. AFAICT, ICMP redirects
shouldn't be limited by the logic implemented by that patch, at least
with default icmp_ratemask. And the algorithm in ip_rt_send_redirect()
has a different purpose, too.
ICMP redirects are sent if I do this, for instance:
echo -1 > /proc/sys/net/ipv4/route/redirect_silence
or
echo 0 > /proc/sys/net/ipv4/icmp_ratemask
Hugo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
