[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200927161031.GB471334@fedic>
Date: Sun, 27 Sep 2020 18:10:31 +0200
From: Baptiste Jonglez <baptiste@...sofnetworks.org>
To: David Ahern <dsahern@...il.com>
Cc: Alarig Le Lay <alarig@...rdarmor.fr>, netdev@...r.kernel.org,
jack@...ilfillan.uk, Vincent Bernat <bernat@...ian.org>,
Oliver <bird-o@...net.de>
Subject: Re: IPv6 regression introduced by commit
3b6761d18bc11f2af2a6fc494e9026d39593f22c
On 27-09-20, Baptiste Jonglez wrote:
> 1) failing IPv6 neighbours, what Alarig reported. We are seeing this
> on a full-view BGP router with rather low amount of IPv6 traffic
> (around 10-20 Mbps)
Ok, I found a quick way to reproduce this issue:
# for net in {1..9999}; do ip -6 route add 2001:db8:ffff:${net}::/64 via fe80::4242 dev lo; done
and then:
# for net in {1..9999}; do ping -c1 2001:db8:ffff:${net}::1; done
This quickly gets to a situation where ping fails early with:
ping: connect: Network is unreachable
At this point, IPv6 connectivity is broken. The kernel is no longer
replying to IPv6 neighbor solicitation from other hosts on local
networks.
When this happens, the "fib_rt_alloc" field from /proc/net/rt6_stats
is roughly equal to net.ipv6.route.max_size (a bit more in my tests).
Interestingly, the system appears to stay in this broken state
indefinitely, even without trying to send new IPv6 traffic. The
fib_rt_alloc statistics does not decrease.
Hopes this helps,
Baptiste
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists