[Bug 287244] [fib_algo] inet.80 (radix4_lockless#865) rebuild_fd_flm: table rebuild failed (route add 255.255.255.255/32 -reject -fib 80)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287244

--- Comment #2 from Paige Thompson <paige@paige.bio> ---
(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    
root@zima.netcrave.local:/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.