I'm trying to identify if the following behaviour is a bug or is normal...

RB1100 Router with max RAM (2GB - 1.5GB supported in ROS). Bootloader = 2.29. ROS = 4.16. Router is idle on 0% cpu - routing <1Mbit/s traffic - I have installed it as a "proof of concept" to see if we could move some of our core routing to Mikrotik. The behaviour described below happens on winbox or direct serial connection. There are around 4 firewall rules and no other services running - just bgp and some static routes.

3 full BGP tables filtering out anything small then a /23. Filters set to reject rather than discard.

"/ip route count-only" shows 770930 (about right for 3x 330000 odd prefix tables)

Say I want to find out what static routes I have I issue :-
"/ip route print where static=yes"
router hits 100% cpu and takes 3-4 minutes to return the 22 static routes I have in place!

If I want to do the equiv of ciscos "show ip route 1.1.1.1" which returns an answer instantly on our cisco routers:-
/ip route print where x.x.x.x in dst-address
same as before - router hits 100% cpu and takes around 5 mins to return the prefix.

So is this a bug in 4.16 or is this normal ROS behaviour?

I can't see it being "normal" as the kernel/routing engine must be able to do a similar query to the one above in fractions of a second or the router would grind to a halt instantly in normal traffic.

Console is fetching all routing information and then trying to find which entries to print, it is quite slow.
Only parameter that can be filtered fast is "dst-address", for example
print specific destination:
/ip route print where dst-address="1.228.36.0/24"

or print all routes within a subnet:
/ip route print where dst-address in "1.0.0.0/8"

Performance improvement is in TODO list.

Thanks for the rapid reply.

The ability to query the routing table without knowing the prefix length is pretty much an essential feature for a core router as it makes debugging impossible to do as you would rarely know the prefix length of the advertised route.

This query at least (in dst-address) should be a high priority update if possible

Do console queries take a lower CPU priority than other processes? Ie would this 100% CPU cause any issues on a busy router?

Yes, console has lower priority, however on very busy routers it still can cause issues.

mrz - ok thanks for the honest and speedy reply

Feature suggestion - None essential this but greatly help when dealing with large numbers of dynamic routes would be in winbox when you go into IP > Routes to display the static routes and filter out any dynamic routes by default. I.e it seems lots of functionality suffers as a result of having large quantities of dynamic routes - so at least allow the user the ability to filter out those routes.

I'm guessing winbox is performing the same commands behind the scenes though so this feature request is probably linked into increasing performance of the queries in general.

or print all routes within a subnet:
/ip route print where dst-address in "1.0.0.0/8"

Performance improvement is in TODO list.

Can this be made to work with IPv6? Winbox does not sort IPv6 routes properly, and the console can't search the table, so it's very hard to troubleshoot some 8000 ipv6 routes manually. Is this something I am missing?

/ipv6 route> print where dst-address in "26205000::/44"
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
# DST-ADDRESS GATEWAY DISTANCE

It does take about 10s for it to search the table, it just doesn't find anything.