The lack of official and public response from Mikrotik, for me, is an evidence they don’t have a clue on why this happens and how to fix it. So, no fix soon, even in the first v6.0. If such severe problem were about to be fixed in the next v6 stable release, they would be annoucing it heavily.
OSPFv3 just doesn’t work, BGP has stale routes… They’ve been too busy devoting all their time to building the CCR which is great and all, but the adage “learn to walk before you try to run” springs to mind. It makes absolutely no difference to me how many packets I can push over a device, how many queues I can have on it (I don’t personally use any - we only trade in wirespeed), if I can’t rely on it having a valid/complete routing table in the first place and know that the packets will actually get where they’re supposed to be going.
I kept getting told that the problems I have will be fixed in “the new routing package” but that they have no real information on when it will be available. There’s no talk at all in the v6 Changelogs of a new routing package, so it presumably still hasn’t been addressed. Like others, I gave up asking support because it was a waste of my time.
I’d have been game for grabbing a pair of CCR1036’s but after buying two of their former flagship tins (RB1100AHx2) to use in a testbed for customer access routing and getting - mostly - no useful support it seems like a waste of time (which is in shorter supply than money) - and I have no reason to believe that support will get any better. By support, I include rolling out software fixes in less than a couple of weeks for major functionality defects rather than things being broken for over a year. I even offered to buy additional licences to bribe them into fixing their product.
It’s actually pretty hilarious to me that the MUM in the US had a presentation from one of the guys at Hurricane about how IPv6 is no longer optional whilst current builds of RouterOS can’t even maintain adjacency in OSPFv3.
I want to back the underdog, but I can’t when there are major problems with the way the product’s firmware is supported. MikroTik don’t seem to get that I and others will spend more money to get a product that just WORKS and they are limiting their own growth potential - refurb/grey Cisco and Juniper is not so expensive as to be an unattractive alternative, because Cisco et al without support is better than MikroTik with support right now.
This strikes me as a dumb position to be in, when you’re proposing to have a box that can shift 24mpps at $1000 and you’re still not coming out on top simply because the software and support is bad - I might need a router, I might want a <$5000 router, but I certainly don’t need - or want - a $1000 paperweight that’s going to tie up hours of my time (which has a very real cost).
The worst of it is that nobody really seems to care. There is no sensible response to any of this. Presumably the WISPs et al are buying enough of the smaller bits of kit to keep the lights on, so why change the model, right?
Great comment!
Here we have to buy a Juniper MX router that cost here about U$30K dollars, but in the last 8 months since we change our x86 mikrotik border router with the Juniper, we have yet to see any kind of issue or hicup. Sometimes I really forget that we have a router running here.
I really “loved” mikrotik router os and products, since 2005 . But when you go large ( full tables, and more routing complexity) it lacks “software” reliability.
I’m really looking forward to try the CCR product, but we will not be able to deploy as a backup router for our Juniper or even in our most crowed PoPs because of these routing issue.
I’m felling betrayed.. 
I suppose it’s fortunate that because I started from a more complex environment to begin with - dual stack full table access routing - that I uncovered the flaws before we got too involved with MT.
If I had spent time getting a certification, and had a pile of their kit, I would definitely be in the CCR announcement thread making myself unwelcome asking if the CCR actually did BGP/OSPFv3 properly or if it was broken (and likely to remain broken for a year+) in them too.
In the absence of any meaningful response from MikroTik, has anyone found a workaround short of rebooting the router every X hours ? I have the same problem with two routers (out of several hundred). Neither do any advanced routing (OSPF, BGP), but both use bridges to terminate VLANs. Each will invariably stop processing IP traffic once the route cache fills up. The rate is dependent upon traffic, one takes several days, the other just hours. Interestingly, you can MAC telnet into the router which at least allows me to remotely reboot from an adjacent device.
Disable and Reenable the affected interface do the trick here. But as I changed our border router from MK to Juniper, I don’t have this issue anymore.
I would try that if the router was not an hour’s drive away. I suppose I could experiment with a script to accomplish this, but it is a little scary if something goes awry and customers are down for hours. They just hate that.
I actually solved my problem by splitting the functionality between two MT routers. One does the VLAN tagging, the other does NAT. Stupid, but what else am I going to do with all those RB532’s … 
Cheers,
Reading this thread is very disappointing. Route manipulation in any dynamic routing protocol needs to function reliably. I was hoping to deploy MikroTik devices at the edge. This thread just killed any future plans with MikroTik with exception for use as a wireless home IP access product.
Respectfully,
–ISO
Aparently this issue is fixed in the new routing package.
It is disappointing it is taking Mikrotik such a long time to fix such a visible, repeatable and widspread fault.
with new routing package?
Staff i have been trying to fix a little issue i had i was basicly adding static routes and removing them
and re creating nats and so forth, and some where along the line one of the routes i am certain of got stuck, but it was not in the route table
it took a reboot to clear the mysterious issue.
I really dont have much in my router but i have rb450g i dont think you need my config in this case
just simple static routes and Nats nothing else
Hello nz_monkey,
Just checking but you mean the issue WILL be fixed right? Do you know something about when that new package will be avaliable?
tks
Hi jthiele, I have no idea when this will be fixed, I am guessing the answer is “When it’s ready”. Maybe Maris(MRZ) or Janis from Mikrotik can provide a better answer
I have just discovered another bug.
During some testing of a dual border router, dual provider setup with OSPF re-distributing a default route between the two border, I discovered that the default route being re-distributed in to the OSPF is being received according to the OSPF routes tab, but does not appear in the main routing table under /ip routes. Oddly, it still appears to be active as I can still reach the router, but it certainly is not appearing in the winbox output!
i see the routing table bug as well. entry’s don’t go away for routing mark till a reboot of the router is done.
please fix or allow flush command.
running 5.22
Yes we have seen this too when using Route Marks with L3VPN.
Hopefully it gets fixed in the very near future.
Anyone try last ROS 6 rc to see if the bug is still present ?
Unfortunately we cant take the risk on production networks
Mikrotik are fully aware of this issue and have acknowledged it, but they have not provided a timeframe in which it will be fixed
We are happy to test new routing code, under NDA if required.
hi guys,
can you give a roadmap how to repeat bgp-cache bug with CCR or 1100AHx2 in LAB?
if necessary i have several copies of 440k routing table to share in iBGP
andis,
Isn`t necessary to have many routes in the table for the problem appears. Here I have ~ 20.000 routes on router
connected to an IXP (NAP).
Some information that can help:
- My peers are IXP Route Servers running Quagga (not 100% sure if quagga still).
- There are routing filters implemented, nothing special. Discarding bogons, and setting community on input filter.
- Mikrotik redistritute learned bgp routes from IXP to a local quagga working a Looking Glass server
What happen:
- If a IXP member stop announcing a prefix it desapears from Mikrotik routing table but Mikrotik keep announcing it to My LG Server
- Despite route not part of Mikrotik routing table, router keep using it to send traffic
- Refresh ou reset on bgp session does not help, reboot needed
Last time it happened to me I had two prefixes from an ASn, one was 186.x.y.0/21 learned from IXP and the other was a 186.x.y.0/20 learned from my transit peer. When prefix owner removed /21 from his announce router ignored /20 and keep sending traffic to /21 gateway.
Hope it helps