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?quer ... k&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?

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.

{rextended} When a structure is leaning over but hasn't fallen yet, where I come from we don't fix it !!
+1000

Fixed for ya buddy!

{rextended} When a structure is leaning over but hasn't fallen yet, where I come from we don't fix it !!
+1000

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:

1. the lack of "dynamic-in rules". e.g. "/routing filter rule ... chain=dynamic-in" isn't available in V7.
See viewtopic.php?t=180157
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)

2. 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.

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)..

Nah, we need full-cone nat first!

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.

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?

Those that want a long-term version: what is the requirement for that?

It's definitely not a new concept in network engineering. Going back over 20 years, Cisco produced safe harbor code that turned into their "star" code for the most stable release within a major version.

Just like any other vendor, all core features (routing/switching/bridging/firewall/queuing) are proven to be stable and only bugs get patched when found until the next version of Long Term is released. This worked incredibly well for ROS v6 and we built a lot of stable networks on 6.48.6 with the confidence that it would work.

So we need feature parity with ROSv6 - when I talked with Janis on the MTU podcast, he said that was a high priority for the development team.

My take is - let's say we get feature parity by summer of 2023 - it will prob be another 2 or 3 months before a version is moved to long term imo. So long term target is prob not sooner than Q3 2023.

Those that want a long-term version: what is the requirement for that?

It's definitely not a new concept in network engineering. Going back over 20 years, Cisco produced safe harbor code that turned into their "star" code for the most stable release within a major version.

Sure, but that is not at all what a MikroTik long-term version is... that is just the previous "stable" version.

My take is - let's say we get feature parity by summer of 2023 - it will prob be another 2 or 3 months before a version is moved to long term imo. So long term target is prob not sooner than Q3 2023.

I wouldn't be too sure about that and just like pe1chl pointed out, I suspect MT will probably follow their usual practice and drop a long-term version pretty soon after the first stable is available.

With this in mind, you really need to follow your own strict release management guidelines (and best practices) and for example wait for any numner of bug fixes during a specific time before even try to throw something from long term into production testing.