https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287244
--- Comment #2 from Paige Thompson <[email protected]> ---
(In reply to Zhenlei Huang from comment #1)
Hey Zhenlei,
Opie@ from the FreeBSD Matrix actually pointed out to me that in my handful of
nets that I -reject, I actually had some overlap with 240.0.0.0/4 and
255.255.255.255/32. that may be the catch I don't have something handy.
Ironically I can't repro this at the moment either but I haven't upgraded, I'm
still running:
FreeBSD zima.netcrave.local 14.2-RELEASE-p3 FreeBSD 14.2-RELEASE-p3 #0
n269524-1eb03b059e5-dirty: Mon Jun 23 13:31:14 UTC 2025
[email protected]:/usr/obj/usr/src/amd64.amd64/sys/ZIMA amd64
Few things, if you really want to be sure;
- I need to make sure I'm using radix4_lockless and it would appear that I am:
net.route.algo.inet.algo: radix4_lockless
net.route.algo.inet.algo_list: bsearch4, radix4_lockless, radix4, dxr
net.route.algo.inet6.algo: radix6_lockless
net.route.algo.inet6.algo_list: radix6_lockless, radix6
yeah I haven't tested that full list of routes but I'd have to think why it
should matter; most likely what was causing it or what has been fixed is how it
handled the overlap between 240.0.0.0/4 and 255.255.255.255/32; the latter
being the absolute longest prefix match possible in radix4.
On an unrelated note, something that noticed today about radix4_lockless if you
try to create more than 64 routes where all 64 have the same length/prefix
match but a different gateway you will get:
add net 0.0.0.0: gateway 10.96.4.31 fib 31: Argument list too long
I think this is a completely pointless thing to do anyway, if there's a reason
why I would I'm at a loss for what it might be. But just in case it matters,
tell me if this tracks:
> radix_lockless Lockless immutable radix, re-created on every rtable
change, tailored for a small FIB with <1000 routes.
My guess... it does in batches by the length and prefix match; I'm guessing
when you have multiple that are the same but a different gateway it does them
all at once and the limit for how many it can do at once for me seems to be 64.
Like I said I don't think it's terribly important, rather I only ended up here
because I was just at a loss for how ospf is supposed to work and had totally
forgotten about nexthop and RTA_MULTIPATH being a thing that routing daemons
can configure but not route(8).
Yeah I mean feel free to close this, if I have the issue again I'll ping
somebody and we can pick this up again at least I feel like I have a better
grasp of how it works to do a little more research myself next time :)
--
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.