This fix should potentially fix the problem when BGP route is withdrawn from routing table, but router still routes packets via that non existent route.
Can you please back port this bug fix to 5.25? We have been fighting this irritating bug for-$&@!ing-ever, and there is no way we can let RC code touch our production network.
Thanks,
– Nathan
Hi Maris,
Should 6.0rc14 fix the issue with stale routes inside VRF’s ?
e.g. routes received via L3VPN.
Regards,
Andrew
/me impatiently waits for the RC download to complete…
Agreed!! Please, if fix really works make a 5.x version!
I can test RC at one or two routers, but not on production net.
By the way, when or where it’s avaliable to download? while looking into download section I have found rc13 only.
Jorge
You can contact support to get pre release version.
+1
thanks.
Can you please back port this bug fix to 5.25? We have been fighting this irritating bug for-$&@!ing-ever, and there is no way we can let RC code touch our production network.
+1
I know rc14 was just recently released, but has anyone been able to reproduce the whole issue again with stuck routes?
We do OSPF peering with our data center with 2 routers in a separate OSPF instance. We then redistribute the default route to our internal OSPF instance.
We have huge issues with the default route from the wrong instance becoming stuck in the routing table. (the proper default route didnt replace it like it should, it was blue in the routing table)
v6 build 17/May/2013 14:04:20
Default route still gets stuck…
I can confirm the issues we were having with stuck BGP and OSPF routes have been resolved by this release.
We still have a number of issues with route filters and have opened a ticket with Mikrotik but so far have had no respinse.
I have problems with filters too. Sometimes if I copy a filter its doesnt work. I need to configure a new filter from scratch to work.
Yes. This is one of the issues. We also found even on new filters sometimes you need to disable/enable them to get them to work. (Yes even with bgp peer refresh)
I did some more testing, and never mind, the issue still persists.
As soon as I take down the datacenter OSPF instance, and then bring it back up, the old default route is still stuck in the routing table.
You can see in the screenshot that the route with distance 121 is installed in the routing table as the default route, altho there is a better route with distance 20, that is blue in the routing table, and not used.
I am very unhappy now…
tomaskir best email support@mikrotik.com and let them know. I doubt they will see it here
Emailed the second I posted 
Lets just hope it gets fixed.
hello
what you show is a default route in instance VNET and a default route in instance DEFAULT
may be coming from this
a+
Thierry
Yes, we peer with datacenter in a separate OSPF istsance, and then have our own internal OSPF instance.
Both instances redistribute a default route, for redundancy in case something fails.
But as you can see, the default route from the wrong instance gets stuck in the routing table when its supposed to go away.
This of course happends only if the datacenter link goes down and then back up.
you have two routes from different OSPF instances installed in the routing table, both with the same distance. the choice is ‘random’, as far as I remember from docs. you may use routing filters to decrease distance of your preferred default route
They dont have the same distance. One is distance 20, the other 121 in OSPF Routes.
They get installed in the routing table with distance 110, because that is default for OSPF routes.
Here is the exactly same router, all I did was reboot it:
