Hey all,
I was looking at the RouterOS license levels and noticed there’s no level 2. The feature gap between 1 and 3/4 is also pretty extreme. https://help.mikrotik.com/docs/spaces/ROS/pages/328149/RouterOS+license+keys
What do you think about a “Homelab” Level 2 license that’s slightly more capable than level 1, and includes software updates? Maybe around $20?
What would be the point of it? License levels 0-6 only apply to MT’s own hardware and all of their hardware comes installed with license level at least 3 (most devices 5, some 4, some 6).
If you’re thinking about CHR (to be run in virtual machine), then look one table lower … license levels Free, P1, P10 and P-unlimited. Pricing is a bit steep as well, but you can go for 60-day demo of any of license levels. After demo period expires, installation continues to work with all demo capacities, it’s just no possible to upgrade ROS version any more.
x86 (bare metal) homelab mostly, but I realize that’s an edge case.
Since ROS support for hardware is mediocre at best, it’s better to go with CHR, running in a VM. Such setup does impose a slight performance hit. As to peripheral drivers (NICs, disks, etc.), it’s the bare-metal OS which deals with them (and a full-featured OS, like proper Linux, supports million times more devices than ROS).
And a benefit: if you want to play with features but don’t care about performance, CHR license is completely free.
It’s a category of question in tech that is as old as time:
“What happened to Windows 9?”
“Why isn’t there IPv5?”
Now, I actually knew the answer to this specific question as I’m an old-timer who was around (had just started deploying ROS solutions) 20+ years ago when this particular version of the ROS licensing scheme was instituted. But for everyone else, MikroTik actually continues to provide the explanation on the very page that you linked to:
Level 2 was a transitional license from old legacy ( pre 2.8 ) license format. These licenses are not available any more, if you have this kind of license, it will work, but to upgrade it - you will have to purchase a new license.
So this implies that there is still license enforcement code within current ROS releases that still has to handle old Level 2 license key edge-cases; as long as this is true, they probably can’t really “re-use” that license level for some other purpose. (Although I admit that, if true, I’m not entirely sure what to make of the “but to upgrade it” language. Unsure if they are talking about version upgrades, or feature upgrades. If the former, then it seems like nothing does actually stand in the way of “re-purposing” the L2 level. If the latter, well, since the beginning of this schema with v2.7, it has always been the case that to “upgrade” a license level involves buying a whole new license at full list price, so it seems kind of silly to even say anything if this is no different than any other scenario. We have no more old drives with “L2” licenses kicking around the office for me to run tests against, though, in order to determine the truth here.)
Frankly, $45 for a Level 4 is cheap anyway and for most intents and purposes is “unlimited”. The only time we ever effectively run into any limitations requiring something higher than L4 is when we want to spin up a massive access concentrator / VPN tunnel server; for those, we just buy L6.
Well this is of course not true. If you want to license a non-virtualized x86 install, those also get the older-style, non-transferable (bound to the original storage/install medium), license level based keys generated for them.
Also as a side note, I forgot to talk about L3 before: this is also an oddball one. It is only available as an “OEM-style” (“preload”) license, which is why the help page says “not for sale”. It basically prevents you from running any WiFi interfaces in “ap bridge” mode (and adds some hotspot restrictions, and perhaps also cannot be used as a CAPsMAN controller…I’m speculating on that last part as I haven’t tested it and the help page makes no mention of this, but it would make sense). It is loaded from the factory on devices that are primarily designed to be used in a scenario where the wireless interface is going to be used as a WAN/WWAN client interface. I thought it was only ever offered on the very old RB112/RB133C products and then was basically abandoned after those were discontinued, but I see from glancing at the product list that it actually has continued to be used on certain newer products to this day. If $45 is somehow too much to spend on a home lab router (especially if all you are interested in playing with is actual routing/packet forwarding, and nothing related to WiFi), perhaps the real play here would be to try to convince MT to offer L3 keys for sale on an individual basis. But I see no incentive for them to bother doing so, really.
Debatable that it is “better” in 100% of cases, and so I’m very thankful that MT continues to offer the non-CHR version of ROS for x86/x64. Buying super cheap, decommissioned, 5-10 year old servers, loading them up with (obviously supported) NICs, and putting those into production with a bare-metal ROS install (where with the older hardware/CPUs you need to eke out all of the performance that you can) has proven to be a very cost-effective, kick-ass solution for a lot of applications. (In every way except, admittedly, for hardware physical heft/footprint/heat/noise and the electricity bill. ) This is especially true for any remaining use-cases where you still need to stick with ROS 6 for the time being, but also need it to be performant & none of the MT hardware that’s compatible with ROS 6 has enough horsepower to be able to meet your needs. (ROS 6 does not support SR-IOV, which can quickly become a problem when virtualized if you are pushing enough packets.)
This, though, is a very good point. CHR rocks for a home lab environment and is easily the cheapest and most accessible way to play with ROS, especially as a learning tool.
The last time I actually checked this field thoroughly (it was a few years ago), MT ceased to support new installs of x86 bare metal devices. I’m not sure if that was official or factual decision though. And the argument was that ROS won’t support most random collections of x86 hardware thrown together. It might be that x86 support is now better (and back in main development line), which in turn means that my (quoted) statement is only “mostly true” 
Well … the top-notch performance, available only on bare-metal installations, is only really necessary in professional environments … where license fee of L6 should not be a big problem. In case you’re describing (get an old, used, server, which consumes tens of euros/dollars a month worth of electricity) IMO doesn’t fit the same bill … in such cases using a virtualization platform (e.g. proxmox) won’t hurt that much … and potentially would save a few tens of euros/dollars because it would run on trial/unlicensed ROS for ever.
IMO such use case compares to home users who buy a CCR2xxx (when in reality, a RB4011/RB5009 or even something lower end, would do just as well) … obviously some people like to spend a lot of dime on something not really necessary … one just have to choose between high CAPEX or high OPEX (my better half is the “high OPEX” item in my life, so I don’t need another one 
)
I don’t know where you came up with that as I’m quite sure that has never been the case. In fact, arguably, with the release of RouterOS 7, it’s better than it has ever been, because with RouterOS 6, the CHR release was the only x86-arch-family release that they “officially” built an x64 kernel for…if you Netinstalled or used ISO image to install to bare-metal, you would only get a 32-bit OS. With RouterOS 7, this is not the case anymore, and even bare-metal installs are 64-bit out of the “box”.
(In reality, the x64 kernel actually shipped with all RouterOS x86 builds, but it was just not officially possible to engage it on non-CHR installs. If you had been around the forums when CHR first was released, though, you’ll remember that unofficial ways were discovered to make non-CHR installs use the 64-bit kernel instead, and that you only had to change one thing one time and the change even persisted/survived through OS upgrades. This was nice, too, since MikroTik ONLY included 64-bit versions of the paravirtualized ethernet drivers for the various supported hypervisor platforms, so if you ran non-CHR installations virtualized with the regular 32-bit kernel, you couldn’t use paravirtual interfaces, just emulated ones. And a fair number of us had been virtualizing ROS since before CHR existed, so when this “hack” to make the 64-bit kernel work on non-CHR was discovered, it meant we didn’t have to re-license any of our existing and already working virtual routers. Just change them over to use the 64-bit kernel instead, and voila: paravirtual ethernet support! Now with RouterOS 7, everything seems to finally be officially unified, so CHR and non-CHR versions BOTH have the exact same set of features and driver support, and the only difference that remains is licensing model.)
Of course. I said earlier that the $45 asking price for L4, for what is effectively an unlimited license for most applications, is cheap. But the same goes for L6. A one-time $250 for what it nets you is one of the best software licensing bargains that has ever existed.
Again, it just really depends on your goals. A few years back, we tried virtualizing ROS on Hyper-V and put plenty of CPU horsepower behind it for a particularly high-load application (that actually involved multiple guests running on the same hypervisor), because at the time everybody said that CHR ran the “best” on Hyper-V (see for example IPA’s video on loading BGP tables on Hyper-V compared to ESXi and Proxmox). All we were met with was frustration and heartache…weird sporadic but inexplicable packet loss as the utilization started ramping up, but no real pegging of any CPU cores. Since this was before ROS 7 had been released, the best we could theorize at the time was that it was the lack of SR-IOV that was killing us, and that although CHR ran well in Hyper-V “on paper”, or maybe when all you were doing was filling and maintaining a routing table, when it came to actual packet forwarding (arguably the most important function of, you know, a router), it wasn’t ready for prime-time. That said, we have (and continue to) virtualized ROS many times for applications with lower demands, and those are fine. So it’s all about picking the best tool for the job.
My answer is: For God sake, what for?
Buy a used device (no need for a computer that ROS could be inastalled on) that would fit your needs for homelab tests.
You can find many offers from 5$ up to 20$ on the Internet. With even WiFi built in.