Vincent I can't agree.
I love the MTK stuff but it just isn't in the same league as our Cisco or Juniper equipment we use.
You run into walls with the CCR's when you do high speed IPSEC transfers and limitations like the 1GB per flow on the 10GB models is pretty infuriating.The OSPF/BGP on the Mikrotiks are buggy as all heck and hasn't been attended to since the 4.XX days.
Definitely 100% true. I love Mikrotik as well, but there are some spheres of operation where a Mikrotik is just a toy compared with the much more robust gear on the network. (sorry - it's just true - again, I'm a huge fan of Mikrotik so don't take this as a bashing post)
What kind of problems do you have. I have a bgp session running OK mikro since 2013 and is working perfect
Routing is definitely buggy and subtly broken on Mikrotik. One glaring example is that default route origination in OSPF doesn't allow floating static backup and it interferes with policy routing from BGP. I spent a few hours comparing simple topologies with Cisco vs. Mikrotik, and Mikrotik consistently exhibits subtle flaws that result in sub-optimal routing or even broken behavior such as routing loops, or backup default GWs that can only be released manually.
For instance, when doing a conditional default-originate in OSPF, a route with administrative distance > 110 will not go inactive if OSPF learns some other default GW.
Suppose you have R1 and R2 both originating default routes into OSPF if-installed-type-2, with R1 metric=1 and R2 metric=2. R1 has a static default GW with ping tests, and R2 has a floating static backup default route. The idea is that if R1's connection goes down, it withdraws its default route advertisement from OSPF and R2's floating static route takes over. R2 now announces the default route based on this floating static route. The problem is that when R1's connection is fixed, OSPF should automatically revert to using R1 as the global default route.
Mikrotik won't do it - even though R2's floating static route has a distance > 110, it won't drop that in favor of the restored default GW announcement from R1 (which would have a distance of 110). This is because the OSPF process completely ignores default routes in the OSPF database while the local router is announcing default GW into OSPF even if this announcement is based on a route that is "worse" than OSPF. This is incorrect behavior. If a better default route is available via OSPF, then the router should withdraw its own advertisement from OSPF in favor of the superior route.
This is a classic configuration that is a no-brainer to implement in Cisco, Adtran, Juniper, etc - yet is broken in ROS.
It causes similar problems when using BGP for the default route if you want active/backup behavior (and iBGP is ALSO bugged in a way that breaks this option).
In ROS, iBGP won't advertise the default GW prefix learned from eBGP. Instead, you must originate a new default route into iBGP which is a bad thing to do - it can lead to routing loops. It's a very subtly different thing to re-originate a default GW into iBGP than to propagate a route from eBGP.
It's also slow and clunky to work with a large routing table in ROS (apparently this is fixed in v7)
New versions of software tend to introduce bugs or re-introduce old bugs.
Basically, Mikrotik is a wonderfully flexible and capable platform that allows advanced users the ability to cheaply do almost anything network-related that they can imagine. However, it has not reached the robustness level of the well-known carrier-grade gear out there.