We are running some full tables on our CCR2216 with RouterOS 7.7 stable. If you open the route list in winbox sometimes the process "routing policy configuration" goes up to 100% cpu usage and stays there. We let it do so for more than a day but it didn't come back to normal.
You can see this with /routing/stats/process/print and see the process time.
As it's not doable to restart the router to bring it back to normal after you accidentially opened the route list, we tried to just kill the process and let it restart with /routing/stats/process/kill. After that the process automatically restarts and router works again as normal.

BUT: Now all static routes have two entries in the routing table. And if you have to kill the process a second time. There are three entries for every route.
So. I understand that you should not just kill a routing process. But the routing process should also not go crazy just because you open routes in Winbox.

1. Why does the process "routing policy configuration" go crazy when I open routes in Winbox?
2. Why does the static routes get added mutiple times when I restart the process?

Cheers
Dennis

When you have (multiple) full routing tables it is not a good idea to open the route list in winbox...
When you need to see the properties of a certain route, use commandline with the proper "where" clause.
When you need to do that often and want a more efficient method, write a program on an external server that uses API to retrieve the info and display it e.g. on an intranet web page.

pe1chl, thats a piss poor answer!

This is clearly two bugs and needs to be reported to MT.
a. winbox should cause no such issues.
b. duplicate routes should not be created regardless........

netwzwerghh, are you familiar with supout???
https://help.mikrotik.com/docs/display/ROS/Supout.rif

I know that it is a bad idea to open the route list in winbox on a full table router. But one of my colleagues did not know when he wanted to change a static route. Also it might happen accidentially that you open the route list. If you do so. The routing process should clearly not go crazy.

anav, thanks. Yes I know how to file a support request. Will do this the next time someone triggers this on one of our routers. I'm not very keane in triggering this behaviour on our production routers now

I have commented before that I think that winbox should offload "filter" actions to the router. As it is now, it will retrieve the full data of the window that you open, and filtering like "Static = yes" will be applied locally in Winbox. So when you have 10 static and 1000000 dynamic routes, it will still retrieve all of them and show only 10.
Of course, it should send the query with "static=true" a filter to the router, and it will return only 10 routes and there is no problem.
But alas, that is a feature request, it does not work that way (yet). But in commandline it does.
For now, you can use a skin to remove the IP route list from winbox (assuming you are running v7).

Hi,

Any news on this?

Is my problem maybe related?
I don't know about the problem of getting multiple static routes.
But i have problem with that the router is geting unresponsive if I open the route list for some time. (with 2x FIRT on ROS-7.16.1)
And that makes BFD to drop packages and as a consequence the router looses ospf adjacency.

BR J

There is now a new winbox in betatest but I do not know if it has improvements in this area.
I agree with you that the route display in traditional winbox does not work correctly now, not only it can really load the router but also it sometimes lags in what it displays compared to what is really in the routing table (i.e. more or less what was reported above).
E.g. sometimes I see *hexnumber in fields, and when refreshing or clicking on that line it changes to the correct text.
Or it shows wrong lines after a lot of updates have been done by the routing process (in my case BGP, but probably the same with OSPF) which is only fixed when closing and re-opening winbox.
I have been hair-pulling to find why a certain route was not in the table only to find when I closed/re-opened that it really was there.