On Tue, Jun 25, 2024 at 10:54:16AM +0200, Claudio Jeker wrote: > On Tue, Jun 25, 2024 at 08:35:18AM -0000, Stuart Henderson wrote: > > On 2024-06-24, Tom Smyth <tom.sm...@wirelessconnect.eu> wrote: > > > Folks, > > > while reviewing nsh I was wondering how to improve show route > > > commands... > > > reviewing the man route man page, > > > > > > there doesnt seem to be a straight forward way of displaying > > > blackhole routes without using > > > > > > route show |grep B for blackhole > > > > > > route show |grep R for Reject > > > > > > is there something Im missing, > > > > > > would I be better off improving route(8) rather than stringing > > > commands together for NSH ? > > > > It's not an efficient operation in the first place; kernel lookup is > > done with the address/prefix as a key and the flags (B/R etc) are only > > found once you've fetched a route (similar if you wanted to e.g. find > > routes with a specific destination router). > > > > In order to find all routes with a certain flag you do need to dump > > the whole route table and check it. > > > > It could be done slightly more efficiently with a check for the > > relevant flag rather than going via a text processing tool like grep, > > but I bet the actual overall time isn't going to be very different... > > > > This is one of the things we need to fix. It is very similar to the > problem arp -an has on bgp routers with a full table. This sysctl to grab > the routing table is horrible and needs to die. >
Actually route(8) could support NET_RT_FLAGS then one could issue a command like 'route show -blackhole'. This could be used as well for -gateway (which should be fixed at the same time to just look at the RTF_GATEWAY flag because RFC 8950 will be a thing to implement). Now arp is already using NET_RT_FLAGS and it is still rather slow to walk the full routing table to grab the arp entries. Guess it is time to look into some profiling data here. -- :wq Claudio
