From: Alarig Le Lay <firstname.lastname@example.org> To: David Ahern <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 11:57:42 +0100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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. > There is no limit on fib entries, and the number of FIB entries has no > impact on the sysctl in question, net.ipv6.route.max_size. That sysctl > limits the number of dst_entry instances. When the threshold is exceeded > (and the gc_thesh for ipv6 defaults to 1024), each new alloc attempts to > free one via gc. There are many legitimate reasons for why 4k entries > have been created - mtu exceptions, redirects, per-cpu caching, vrfs, ... I also tried to find a sysctl to ignore the MTU exceptions, as a router it’s not my problem at all: if the packet is fragmentable, I will do it, otherwise I will drop it. The MTU negotiation is on the duty of the ends. I’m not taking the MSS clamping in account as it’s done with iptables and the mangle table is empty (but CONFIG_IP_NF_MANGLE is enabled). > In 4.9 FIB entries are created as an rt6_info which is a v6 wrapper > around dst_entry. That changed in 4.15 or 4.16 - I forget which now, and > the commit you reference above is part of the refactoring to make IPv6 > more like IPv4 with a different, smaller data structure for fib entries. > A lot of other changes have also gone into IPv6 between 4.9 and top of > tree, and at this point the whole gc thing can probably go away for v6 > like it was removed for ipv4. As it works on 4.15 (the kernel shipped with proxomox 5), I would say that it has been introduced in 4.16. But I didn’t checked each version myself. > Try the 5.4 LTS and see if you still hit a problem. 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. Regards, -- Alarig
next prev parent reply other threads:[~2020-03-08 11:05 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 [this message] 2020-03-09 2:15 ` David Ahern 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).