From: David Ahern <firstname.lastname@example.org> To: Alarig Le Lay <email@example.com> Cc: firstname.lastname@example.org, email@example.com, Vincent Bernat <firstname.lastname@example.org> Subject: Re: IPv6 regression introduced by commit 3b6761d18bc11f2af2a6fc494e9026d39593f22c Date: Sun, 8 Mar 2020 20:15:14 -0600 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 3/8/20 4:57 AM, Alarig Le Lay wrote: > On sam. 7 mars 17:52:10 2020, David Ahern wrote: >> On 3/5/20 1:17 AM, Alarig Le Lay wrote: >> Kernel version? > > I’ve seen this from 4.19 on my experience, it works at least until 4.15. > >> you are monitoring neighbor states with 'ip monitor' or something else? > > Yes, 'ip -ts monitor neigh' to be exact. > >> The above does not reproduce for me on 5.6 or 4.19, and I would have >> been really surprised if it had, so I have to question the git bisect >> result. > > My personal experience is that, while routing is activated (and having a > full-view, I don’t have any soft router without it), the neighbors are > flapping, thus causing a blackhole. > It doesn’t happen with a limit traffic processing. The limit is around > 20 Mbps from what I can see. If you are using x86 based CPU you can do this: perf probe ip6_dst_alloc%return ret=%ax perf record -e probe:* -a -g -- sleep 10 --> run this during the flapping perf script this will show if the flapping is due to dst alloc failures. Other things to try: perf probe ip6_dst_gc perf stat -e probe:* -a -I 1000 --> will show calls/sec to running dst gc perf probe __ip6_rt_update_pmtu perf stat -e probe:* -a -I 1000 --> will show calls/sec to mtu updating perf probe rt6_insert_exception perf state -e probe:* -a -I 1000 --> shows calls/sec to inserting exceptions (in each you can remove the previous probe using 'perf probe -d <name>' or use -e <exact name> to only see data for the one event). > I have the problem with 5.3 (proxmox 6), so unless FIB handling has been > changed since then, I doubt that it will works, but I will try on > Monday. > a fair amount of changes went in through 5.4 including improvements to neighbor handling. 5.4 (I think) also had changes around dumping the route cache.
next prev parent reply other threads:[~2020-03-09 2:15 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-05 8:17 Alarig Le Lay 2020-03-08 0:52 ` David Ahern 2020-03-08 10:57 ` Alarig Le Lay 2020-03-09 2:15 ` David Ahern [this message] 2020-03-09 8:59 ` Fabian Grünbichler 2020-03-09 10:47 ` Alarig Le Lay 2020-03-09 11:35 ` Fabian Grünbichler 2020-03-10 10:35 ` Alarig Le Lay 2020-03-10 15:27 ` David Ahern 2020-03-29 14:09 ` Alarig Le Lay 2020-09-27 15:35 ` Baptiste Jonglez 2020-09-27 16:10 ` Baptiste Jonglez 2020-09-28 3:38 ` David Ahern 2020-09-28 5:39 ` Vincent Bernat 2020-09-28 6:48 ` Baptiste Jonglez 2020-09-29 3:39 ` David Ahern
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: IPv6 regression introduced by commit 3b6761d18bc11f2af2a6fc494e9026d39593f22c' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).