Hi,
Every now and them we got that problem. Today another AS network engineer called me becouse his IP prefix couldnt reach our prefixes.
After troubleshooting he told me that they lost they connection in a national wide IXP and when doing a traceroute from our bgp router, the next hop showed was our IXP ip address. After checking the routes, we’re receiving their routes via another service provider but RouterOS were trying to get to them via a cached route that doesnt even exists anymore.
To fix the problem we have to disable the IXP interface on our router and them reenable it. After that RouterOS finnaly forgot the route and them everything started to work.
Anyone more having that problem? Is there any command to clear routing cache?
I don’t think there is a command to flush the route list/cache. It generally does this automatically. You should contact support@mikrotik.com and request such a feature or workaround.
This specific bug is causing some frustrations for me as well. It appears that the stale route remains in cache for as long as any IP sessions are trying to make use of the path. In this regard think of any TCP connections that might need to time out etc - the route could therefore stay in cache for far longer than one would reasonably expect. From past reading it looks like items typically expire from the cache after around 10 minutes - but not for ‘in-use’ routes.
The forcible shutting of an interface has on occasion not solved it for us - and we actually had to perform a reboot.
This is one of the frustrations I hope gets addressed on next RouterOS builds. While being able to forcibly manually clear the cache would help it would be better for TIK to remove ‘in-use’ routes if the routing entry supporting it is removed from the main routing table.
Thank for your statement about that bug. Please open a support ticket. So way the MikroTik trama will see that more ppl have the same stuck route problema.
The same problem.
I have a test that pings the remote server. Sometimes the ping test fails but all the devices on the way are UP and running. Disabling and enabling route to this destination on mikrotik solve the problem.
Im experiencing this problem on 3 x86 (5.7) and 1 RB433 (5.14).
I have exaclty same problem reported at top of this thread (dec 2011?!?). Two routers connected to IXP and when
a peering partner stops sending a prefix my router removes old route from table but still trying to use that
route to forward packets… and worst still sendind that prefix through ibgp to my core router.
Im wondering if that problem still the same problem reported in 2011 or its is new. Hope its new because
one year to solve a routing problem is too much if you have in mind we are talking about ROUTERS.
Still present, yesterday I have the same issue again with a router with a low route count ( about 300 routes). I had to disable and reenable the interface that had the stale stuck route and everything back to work..
I don’t know why RouterOS guys fix this or create a tool to clear the route cache.
You should take in consider that BGP need time to be updated.. its not like of other routing protocol.. update the route DB as soon ad there is change apear in network..!!
So you have to wait even my take up to 5min..!!! till most of Upstream provider got the update..!!
Also there is another option is that you can refresh you peer update / routing bgp peer refresh-all afi=ip
The bug related here is that even if you wait a month, if you dont reboot the router or disable and reenable the interface that the related bgp route were using, the traffic destinated to that destination will use the stale route for ever..
As I said before, route disappear from routing table… Looks like bgp receive routing update from neighbor, remove it from routing
table but it still present on route-cache. What I dont know is why the removed prefix keep advertised to other routers.
As far I know, bgp use messages to update routes, it dont have a holdown timer to wait before removing a route, like RIP does. (Im talking about updates and not neighbors timers)
On my case routers a connected to IXPs and prefixes are exchanged by MLPA on those IXPS, what give me only 11.000 prefixes and
updates occour only inside that group.
I`m going to downgrade to version 3.27 and see what happens. Support told me that problem is known since 4.x.
But I did it only on RB1000 hardware because RB1100/RB1200 dont support that version.
Also… I downgraded to 3.30 and Im using default routing package, looks like routing-test is the same used as default routing package on versions > 3.30. \ \ Donf forget to check if 3.30 can do all tasks that you need on your router, mikrotik did a lot of improvements
5.x versions.
Here in Brazil, the biggest IXP in South America (PTT-SP) there is a mailing list in which several users posted they are suffering from the same problem (with different ROS versions) and also complaning support tickets are left unanswered. Some companies migrated to Quagga because of that issue (and mainly due the lack of consistent response). I strongly suggest this issue to be reviewed with a higher priority.
I`m one of those users connected to PTT-SP and saw a thread on [GTER] list about that problem just after my first post here.
Also… I definitely agree with you about mikrotik must increase priority to solve this bug.
C`mon Mikrotik help us to keep supporting your products! give us an workaround at least!
same problem with OSPF routes… I sure it is a basic problem with routing package
I send many bug report to support and each time answer is “it will be fix later”… time after time…
