Or nothing at all…
Ticket#2013050266000072
Ticket#2013043066000404
Bad news guys - x86 RouterOS 6.0 still has the route cache bug.
We receive a customer route via EBGP (1); forward it internally on our IBGP (2) to one of our peering edges(3). This edge then EBGPs with a number of peers (4).
Even after removal of the announce by (1) the edge (3) continues to announce the route to our peers (4).
Grumble. I hate to say it … but ITS NOT FIXED
regardtv it is a different problem. We fixed problem when route was withdrawn but router continued to route packets using that non existent route.
Do you have a test setup where we can connect and see the problem?
Hi ,
Thanks for the reply. All information (including multiple sup-outs) included in Ticket#2013052366000443 ( yes, origional subject incorect 
Just to add to that for the rest of the Mikrotik user base:
[Client] --eBGP–>[RouterA] --iBGP–>Core[RouterB & RouterC] --iBGP–>[IXP Edge RouterD] --eBGP–>[IXP Participants RouterN]
Scenario that seems to cause the issue:
- Customers announce routes to RouterA
- Customer withdraws routes to RouterA
- RouterB & RouterC see the withdraws and pulls them
- RouterD removes the route from its routing table ( as instructed by B&C)
- RotuerD continues to announce the withdrawn routes to RouterN
- Traffic from RouterN for the withdrawn route sent to RouterD is forwarded to Router B&C as if the route is still there.
This is identical behaviour in 5.16 as well as 6.0 (both x86 based).
While I don’t dispute that it may be a separate bug - it certainly presents identically – ie the same issue occurs.
Come on guys time for that devel.npk
In terms of test setup - contact me in the ticket and lets see what we can do
We too are experiencing this issue. Our symptoms are similar to regardtv
I have supplied screenshots and supout.rif’s from our RouterOS 6.1 testing in Ticket#2013061366000148
What we are seeing is
RT00 VRF --L3VPN–> RT01 VRF
–L3VPN–> RT02 VRF
RT00 originates a route, this is seen by RT01 and RT02. If the route is withdrawn, it will only sometime be removed from RT01 and RT02. If it is NOT withdrawn, the only way to remove it from RT01 and RT02 is by rebooting them.
We noticed that if the route is originated then withdrawn within about 30 minutes, it seems to work flawlessly. It is only when the route has been received bt RO01 and RT02 for more than 30 minutes, and is then withdrawn that they will not reflect the change.
When the route is stuck, the CPU usage shown in Winbox and /system resource print jumps from 0% to 25% but the Profiler does not show which process is causing this.
nz_monkey,
Thanks for the confirm - just a question - you running a mixed Cisco & Mikrotik BGP environment? I’m trying to localise as far as a I can and my “all mikrotik” testbed is just not able to recreate it.
My production environment is mixed Cisco/Mikrotik on the iBGP side.
regardtv
No it is happening on a 100% mikrotik test bed
There are still issues on v5.25 with the route cache. If you are using route redistribution for static routes (for example) then even if you delete a route from the routing table, the route will sometimes get advertised as redistributed. Disabling the peer and then enabling the peer does not do the trick.
Only a flush for the cache would do the trick.
+1 for that.
Regards,
Mihai
As per the prior posts here the fix is NOT in the v5 series - I agree flush cache would help but the reality is that we as users should be following the v6 release chain now - and helpling Mikrotik squash bugs… if only they’d get back to me on my open ticket
They are possibly working on the problem 
HI,
This problem solve? My CCR36 make stuck route with iBGP quagga / CCR. News?
It is not fixed. Mikrotik are too busy working on other things to fix it.
Log a support ticket with support@mikrotik.com and include supout.rif
Hopefully if enough people log tickets they can give the problem some priority.
I’m post new " [Ticket#2013073166000808] RE: Stuck routes BGP ". Let’s see how they respond.
It seems that this is the more critical problem about Mikrotik.
It’s the only reason I’m not using Mikrotik for BGP, but certainly I’ll do after fixed.
Again occurred. iBGP routes with fangs disappear after the eBGP. I had to download all the Peers of CCR to normalize. When Mikrotik will fix this?
Hi Jonatas. You’ve forgot to mention the RouterOS version which you experienced this problem.
We are seeing this behavior on 5.12, 5.14, 5.16, 6.0, 6.1, 6.2
We often will get routes that are not in the RIB but exist in the FIB. We have to add static routes manually to over ride them 
I am really looking forward to 7.0 and the “new routing”. We are experiencing multiple separate major issues with routing on RouterOS v5 and v6.
Hello guys!
Any news about this famous issue?
Just remembering its 2nd aniversary since I saw this on MK routers.
It seems to be fixed in 6.5
Can anyone test and report in this thread?
In the 6.5 changelog: route - fixed crash that could be triggered by change in nexthop address resolution;