I am curious after looking at the results of how many devices that can be seen on Shodan that are on ROS7 as to why most in the community don’t upgrade. https://www.shodan.io/search/facet?query=mikrotik&facet=os For me at least its mostly because of BGP route aggregation. I am just was curious what others in the community think are show stoppers for them. Thanks and route on. 
Mainly the non-availability of BGP attributes within a vrf. But the lack of a long-term version is another important reason.
I’ve yet to deploy it on the 802.11ad gear (wAP 60, Cubes, LHG60) because of stability issues others have mentioned on the forums, but the three Cubes I’ve upgraded to 7.7 have been just as stable as with 6.49.x. I think in that case, the Cube SA’s are having the majority of the problems, not so much the 802.11ad models and Cube Pros.
Soon I hope to mass update my customer’s hAP AC2/AC3 routers. The handful running 7 are doing just fine.
I have my whole network running V7
A couple RB433’s protested (they didn’t like having ether2 on one bridge, and ether3 on another, and the ancient IC+ switch chip mixed up the ARP tables)
other than that, a good 200 devices running V7 with some caveats
7.4 and 7.5 were stable
7.6+ introduces some problems. DNS is gone/unusable from 7.7 (but i had abolished “allow remote requests” long ago, so mostly unnafected)
My guess is that people are affraid to update because people are affraid to upgrade.
even within 6.x there are the 6.48.x faction, the 6.49.x faction, and the “i won’t touch it till it dies” faction.
most of those are not proficient enough to fix their setup if something breaks (the won’t touch crowd), and/or lack the time/patience to vet the migration to V7.
Plus (from what i’ve seen), the changes in the routing path significantly alter some failover setups (those that rely in recursive routing, for instance)
so most people are not exactly salivating on the idea of upgrading hundreds of remote locations with site-to-site+failover setups.
My only valid reasons to upgrade are:
- Security issue fix
- Fix for bug in feature that’s actively used
- Significant improvement in performance of feature that’s actively used
When device is doing what it should be doing, it’s stable and there are no known security vulnerabilities on it, why upgrade it?
+1000
Our showstopper is MPLS experimental bits not yet working properly, as it has been for months. Moving to ROS 7 now would destroy our QoS completely.
Mainly the problems with/around BGP:
- no BFD
- lack of a comprehensive “Peers” window that shows the current state of all BGP peers (connection active, uptime, number of prefixes, etc)
- “automatic config migration” issues (filters without explicit accept, peer update-source set to interface name)
- apparent lack of active development
(I do not use VRF, VPNv4 etc so not really affected by the problems apparently present in that area)
Mine is mainly me having time to learn the differences. I don’t do anything overly fancy other than multiple routing tables and I understand that there are some changes there. For me, October - January is really busy for me. So some time in the next couple months I will get to it.
At home it’s 6to4 instantly crashing system (SUP-97719). I need it to work, because it’s still my source of IPv6 (ISP didn’t yet manage to provide native IPv6 and I don’t like third party tunnels). It might be useful indicator of v7 maturity. Given its low popularity, when they fix this, they probably fixed all other more important things (ok, I know it’s not guaranteed). Elsewhere it’s mainly that v6 is enough, and if it works… But soon I’ll probably start to upgrade some devices for Wireguard, it’s not absolute must, but I like it and I’ve been waiting for too long already.
Write a reply to this: “What are your show stoppers for migrating to ROS7?”
Hi everyone!
Main router still v6, as I can use an RB450Gx4 for Ver7 wireguard and testing of other functionality. Will probably wait for the first long term stable of Ver7 to move main router.
Fixed for ya buddy!
Negating the question, I’m forced to use V7 because it has MBIM. Only non-LTE devices are still V6. Now V7 does get me zerotier and let’s encrypt, but I’d still be using V6 if it had MBIM. SSTP worked well enough (and still a backup to ZT in V7).
So my “theoretical showstoppers” blocking some upgrade to V7 be:
-
the lack of “dynamic-in rules”. e.g. “/routing filter rule … chain=dynamic-in” isn’t available in V7.
See http://forum.mikrotik.com/t/v7-filter-dynamic-in-set-check-gateway-option-not-found/153188/1
The dynamic-in stuff was the better way to set “check-gateway=ping” – I love their scripting language but really don’t like it on some critical path (like the DHCP client for some remote site with only LTE connection) -
I don’t deal regularly BGP, so presumably someone like the new V7 BGP scheme. I’m not sure what the problem with the BGP configuration in V6 that required inventing an entire new language for it. But the ship long sailed on this one. Obviously the lack of BFD be blocking me first if I used BGP, in this theoretical world.
Nah, we need full-cone nat first! 
One nice thing about the v7 BGP is that you do not necessarily need a BGP peer configuration entry for every connected peer, especially when you setting up a central router in an organisation where many “client” routers connect and want to exchange BGP information. You can make a single connection template that services many connections. In v6 I have such setups and e.g. one has 67 BGP peers defined, each with their IP address and AS number, which probably could be reduced to one or two connection templates with v7.
However, that would not be a critical new feature for me, as for such peers I need to setup tunnels and firewall rules anyway, and I just made a large number of preconfigured BGP peers in disabled state, which I can easily enable and enter the AS number. Not a big deal for me, but maybe others have insisted on having that.
The new “routing filter” also was apparently asked for by larger customers, but I think it is not an improvement, especially as the GUI does not support it. It now is a similar situation as with scripting: you have to enter filter rules in a plain window without any syntax help. Debugging is a tedious affair. That all was so simple with v6 and for my routing filters that worked just as well.
Also, it looks like the developer of the new BGP configuration was not really familiar with MikroTik configuration language in general.
Worst of all, it looks like that developer has left. All development in this area has come to a standstill, and only some bugs are being fixed, no new features have been seen for a long time. BFD has been “a work in progress” for a year and a half. That is a bit worrying for me.
We’ve migrated a lot of client networks to ROSv7 or to mixed ROSv6 and ROSv7 environments
A lot of it hinges on the complexity of routing in the existing network - simpler OSPF/BGP/MPLS networks seem to be running well on 7.7. Those with more complicated feature sets seem to uncover bugs faster due to “feature stacking”
Biggest show-stoppers we’ve encountered are:
No Long-term version
Lack of BFD
Limitations in VRF and Route Reflection
IPv6 fastpath
CCR2k gear reboots/crash (usually related to firewall rules or connection tracking)
MPLS Throughput issues (still trying to nail down the origin of this problem)
We are running on 7.5 only to have a standardised deployment across all devices, but waiting desperately for a 7.x long-term version to be released. I’d really like to know that is holding back…
I agree with r00t, as long as:
- There are no security issues
- the release is still officially supported
- We don’t need any for the new features (which might introduce new bugs and side-effects)
- An upgrade would not increase performances significantly
…then I don’t upgrade.
Those that want a long-term version: what is the requirement for that? It is not like the long-term version at MikroTik has some sacred status. New versions are sometimes promoted to long-term at the moment of release, without any prior field-testing. I could understand the desire to have a long-term version when it is especially well tested before being promoted, but that is not what is happening. Making enough requests for a long-term release could make them promote 7.7 to long-term. How does that help you more than deciding for yourself whether it is a good release to use?