Hey everyone, my whole network is running RouterOS 6.48.6… v7 has stablalzied to a point (At least the features I need) that I want to upgrade my whole network to V7. The question is this…
Would it be smart to do a two-step upgrade… meaning go from 6.48.6 to 6.49.18 and then to 7.17.2? Or should I just go straight to 7.17.2?
But BEFORE anything else, check the devices you are using, if there are any with 16 Mb storage, MAKE SURE that you have enough space for the upgrade, or rethink your strategy, or be prepared to netinstall sessions.
Tbh I would say, for this kind of major upgrade, the only sensible reliable way to do it is do make a complete /export (including bits that normally don’t get included along like user/group configs or certificates), nuke with netinstall, and re-config from scratch using the old export as baseline, but adjusting to the new methods and changed items.
If you go the upgrade path using ROS buolt-in package updater, then 7.12.1 is required step. It’s tge version which “knows” to install separate wireless package, existing from 7.13 onwards (which can then be uninstalled if you don’t need any of functions provided by wireless package). Up to and including 7.12.1, wireless is integral part of routeros package and can’t be removed.
In ROS v6 it was possible to “unbundle” installation and hence to uninstall wireless package (o any other not needed, such as routing). However, upgrade from “unbundled” v6 to v7 was not possible … until now? Not sure about what exactly means this entry in list of changes for version 6.49.18:
*) system - fixed v6 to v7 upgrade from separate packages;
If it doesn’t mean what I implied by quoting it in this topic, then the only way of ipgrading “unbundled” v6 to v7 is by doing netinstall … and when doing netinstall, one can go directly to any version (even to latest beta if so desired). And that has some benefits as @wrkq explained.
Everyone has his/her own requisites and approaches, but if you remained for so long on an old version, not even latest 6.x version, It should mean that there is not that much need to update to 7.x.
The fact Is that 7.x needs more resources than 6.x, or if you prefer It Is usually slower on limited resources devices than 6.x when doing exactly the same functions.
Wifi (vs. wireless) drivers ( on ac hardware) would make sense, as the new drivers are better, but if you don’t use wireless interface you won’t have any particular advantage.
Same goes for the difficulties/risks in upgrade, if you have simple configuration and enough storage space you should have no issues in doing a “normal” upgrade, the more complex procedure with export/netinstall and manual rebuild of the configuration Is of course “cleaner” but probably not strictly necessary.
If you have complex configuration and little space It suddenly becomes your better (or even only) option.
If your network Is working fine, you can just update the “weaker” devices to latest 6.x and only update the newer/more powerful devices to 7.x.
Also, you don’t really-really need latest 7.x version if everything works, unless there are some new features that you want to experiment with.
I use OSPF, with around 176 routers, and over 2,000 routes… and that’s with using route summarization. Really the biggest reason to upgrade to get the improvements from ospf.
I’ve upgraded some v6 to v7 where a netinstall and configuring from scratch were not possible.
It mostly works, but the automatic configuration conversion is a bit rough around the edges where various default values have changed (e.g. IP / IPv6 max-neighbor-entries, LTE APN, OpenVPN server auth), or are created (e.g. BGP & BFD).
The OSPF conversion is rather hit or miss as interfaces and networks are replaced with interface templates, and also doesn’t seem to handle stub areas (in this case being used to aggregate PPPoE connection addresses) well. If it gets the conversion badly wrong you could loose connectivity if you are completely reliant on OSPF routes.
The only definite error I have found is the DHCP option matcher conversion which incorrectly uses code 43 rather than 60 - the client to server request contains option 60 (vendor class identifier), the server to client reply is usually option 43 (vendor specific information).
I have V6 installed everywhere with extra packages and I have to upgrade to V7 on a lot of devices because it reports low disk space. I thought the latest version 6.49.18 should solve this but unfortunately it doesn’t solve anything at all
Generally v7 requires more disk space than v6 for same feature set so if your v6 devices are running low on disk space, upgrading them to v7 mostly won’t help.
but not at all
for example, the LHG 60G device has just 16MB flash drive, has a good processor, has a lot of RAM.
the whole problem is that I use extra packages V6 and V7 canceled extra packages, so the whole upgrade process is a problem and mikrotik has not solved it yet
I fail to see with which part of my previous post you don’t agree? Specifically I’m writing about disk space which is even tighter on v7 in general (yes, there are a few marginal cases where v7 might even leave more disk space than v6), I’m not saying anything about RAM or CPU availability and consumption.
Unless there are features that you ‘need’ I would highly suggest sticking with 6.48.6 (6.49 introduced an issue with SSH on some clients that they refuse to fix. If you use Solarwinds you’ll have issues)
V7 still has bugs and a lot of annoyances. It’s largely stable enough to run but I would say still not as stable as 6.48.6 and unless you desperately need something in V7 its not compelling enough to upgrade
They are seemingly more focused on silly side projects than actually bringing the routing and switching functionality up to industry standard. MikroTik is like a distracted teenager at this stage, too busy smoking pot behind the shed, dreaming about fanciful things that are largely nonsense and falling even further behind in grades
My previous reply didn’t post, so here is the short version: v7 requires more resources - new kernel, new features + code…all of which may or may not affect how you use your devices.
OP, most devices have issues and workaround posted at this point. Sadly, you will need to try each device to see if the upgrade path is worth it for you. I reverted because I had issues, but many users are more than satisfied with the upgrade. However, there’s a time when everyone needs to upgrade their HW. And, realistically, v6 is in survival mode at this point…
How so?
There are no vulnerabilities or issues on 6.48.6
V7 is there if you want your routing/switching engine to revert to ‘beta testing’ status but you desperately want things like Wireguard and VXLAN. Hardly essential features in every deployment, but there are plenty of things in V6 that are rock solid and V7 is still woeful and playing catch-up. BFD for instance is very rock solid in V6 but absolutely bloody awful in V7. Some hardware it works fine, some it doesn’t and will cause link flapping
I don’t mine using V7 for end user devices but its still on shaky ground for core/distribution/edge equipment
Personally i’m hoping they just give up on V7, it started off as this mythical beast that would fix all the problems that people posted on the forums, turned out to release with a very out of date kernel and way behind on functionality and features that are still buggy. Scrap it and get started on V8 with an up-to-date kernel and open source routing engine so we can get finally get things like IS-IS, MPLS SR, SRv6, FRR etc. MikroTik wouldn’t need to re-invent the wheel and could actually build upon a solid base instead of whatever the hell V7 is, it’s been out for far too long for it to still be unreliable and buggy, at this point it should be absolutely rock solid and significantly feature rich over V6, instead it’s a mish-mash of sometimes-maybe-good-sometimes-maybe-shit