Not sure if this question should go here or in the BGP forum, but I'll start here.

I have a RouterBOARD with a full BGP table, so 400K+ routes plus some OSPF routes.

If I wish to see if there is a route for a particular netblock or IP address in the table and do something like:

/ip route print where x.x.x.x in dst-address

This takes a very loooong time to return. I assume that is due to the size of the table, but I'm talking like nearly a minute to return. I'm used to doing a "show ip route x.x.x.x" on a much less powerful Cisco and getting a response in a couple seconds. Am I doing something wrong or is this just the way it is?

Thanks

Steve

Hi ssaner,

what RouterBoard model and version are you using and what is the CPU utilisation before and while running the command?

On an x86 (1.8ghz dual core) test box with approx 10k routes the search takes under a second to output a result.

He he )) Its a very old issue with ROS )
If you have route tables with more than 100k routes - its a nightmare to search route in table )) in winbox or in console .. I have border with 3 full bgp tables )) i prefer do not open routes in winbox ). And again - in linux or Freebsd, with quagga or bird , all ok, i can find one route in second...

He he )) Its a very old issue with ROS )
If you have route tables with more than 100k routes - its a nightmare to search route in table )) in winbox or in console .. I have border with 3 full bgp tables )) i prefer do not open routes in winbox ). And again - in linux or Freebsd, with quagga or bird , all ok, i can find one route in second...

Thanks for the response. That's what I was afraid of. I take it that there is no work around?

Try using a slightly different command:

I think you'll find that a lot quicker !

(Just tested on a router with 3 BGP feeds)

Hope that helps

Nick.

Try using a slightly different command:

Code: Select all

 /ip route print where dst-address in x.y.z.0/24

I think you'll find that a lot quicker !

(Just tested on a router with 3 BGP feeds)

Hope that helps

Nick.

Hmmm... Well, yes that is very fast, but it doesn't always get me the result I desire. It only finds routes that are /24 or longer. What if there is a route that has a shorter netmask? I guess I can successively look for /23, /22, /21, etc, but that becomes a pain pretty quickly.

Given the above comment that this is an old issue, does Mikrotik have any plans to fix this that anyone knows about?

Thanks

Start you query with a big netmask then

just use /16 to start with