MikroTik Solutions

Run RouterOS on Your Switch
Login

Run RouterOS on Your Switch

Help

Motivation

MikroTik currently has 17 products in the CRSxxx line that can dual-boot to either RouterOS or one of their SwOS variants. Given that it is generally a bad idea to try to use a switch as a router, doesn’t that make the choice obvious? Shouldn’t you always use SwOS on switches, for this very reason?

No, you should not. There are whole classes of reasons why it’s better to run RouterOS on your CRS switches when given the choice.

Command Line

The first class of reasons to prefer RouterOS comes down to its command line interface, a feature SwOS entirely lacks.

Text vs GUI

We care about this for the same set of reasons CLIs are superior to GUIs for systems administration in general. This isn’t the place to give the argument if you’ve never encountered it. One good — if amusingly dated — long-form argument is Neal Stephenson’s In the Beginning Was the Command Line, available in both online and dead-tree forms.

For our purposes here, it suffices to point out that a single short command can be copy-pasted into a chat or forum post far more easily than producing and sending a PNG with a lot of red arrows to depict “click this, then this, then this…” Likewise, the output of that command is more easily copy-pasted into a reply than a series of screenshots. Atop that, screenshots are generally unsearchable, despite the widespread availability of OCR tech. You cannot, for one example, use your browser’s Search feature to learn whether a posted screenshot contains “192.168.88.” when working out how far from defconf your respondent’s configuration is.

SSH

This follows on from the first reason, but is distinct. Once you accept that you prefer a CLI for certain tasks, if not all of them, then you want a modern CLI protocol. That’s SSH; accept no substitutes.

If there are any products still shipping that are limited to Telnet or another equally insecure CLI interface, that’s reason by itself not to purchase them. In-service products that still allow use of Telnet for remote management should have that feature disabled if there’s anything better. This includes RouterOS!

Serial consoles have their points, but I prefer to fall back to that in emergencies only. For day-to-day use, SSH is superior on multiple axes.

Text Backups

SwOS offers binary backups, only, along with all of their attendant problems.

The situation under RouterOS isn’t perfect, but it’s better.

Device Cross-Compatibility

Most SwOS devices have their own distinct firmware releases. While it may not surprise you that the version of SwOS for a CSS610 won’t run on a CRS328-24P, nor vice versa, this is true even for close family-mates like the CRS326 flavors, for which there are three different firmware builds. The features exposed in the assorted SwOS web UIs vary in lockstep with the hardware feature set.

While RouterOS is subject to these same variations in the SoC feature set, there’s an important difference: RouterOS tends to paper them over by devolving to a software version of missing hardware features. Instead of the two-dozen-ish current builds of SwOS — nearly one for every distinct device — MikroTik produces exactly one build of RouterOS for each CPU architecture they support. All ARM64 devices use the same build of RouterOS, as do the MIPSBE devices, etc.

In cases where performance isn’t paramount, you can safely hand-wave SoC feature set differences away by saying “RouterOS Is RouterOS Everywhere.”

Encryption and Security

The SwOS web UI is HTTP-only. You cannot give it a TLS certificate, not even manually, much less set up something like Let’s Encrypt with renewal automation.

RouterOS offers multiple encrypted management options:

  1. AES128-CBC for WinBox
  2. SSH with modern crypto including Ed25519 keys
  3. TLS 1.2 for WebFig and the API

Atop this, SwOS imposes an arbitrary 18-character limit on passwords, an implicit sign that it is storing them in plaintext on the device, not salted and hashed according to widely-acknowledged best practices.

Superior SoC Feature Control

Even within the switching domain, RouterOS offers considerably more control over a CRS class switch than any version of SwOS. The following is meant as a list of examples rather than a comprehensive delta of these two operating systems’ switching features.

VLANs

RouterOS’ support for VLANs is famously complicated, albeit more capable.

A prime example of this is L3HW inter-VLAN routing, something SwOS simply cannot do.1

When SwOS suffices, it may be an objectively better option, but you’re gambling that your needs will not expand to the point that you require RouterOS features to proceed. Alas, there is no easy migration path between SwOS and RouterOS, not even on a dual-boot device.2

Spanning Tree Protocol

STP is a core concept in switching, and while some make arguments of varying quality for disabling it, it’s enabled by default on MikroTik switching products for solid reasons. We may therefore wish to base our product selection decisions on how capable the STP implementation is.

The single biggest difference here is that even on dual-boot products, SwOS lacks MSTP support.3

QoS Controls

SwOS offers rudimentary QoS control, amounting to little more than simple rate limiting.

RouterOS’s QoS controls are deep and wide, and atop that, you have the RouterOS is RouterOS Everywhere aspect to fall back on when using switch products without hardware QoS.

Bonding Controls

Much as with QoS, you get far more control over interface bonding on a dual-boot CRS box under RouterOS than with SwOS, which offers basic LACP LAG only when it offers any LAG support at all.

Multicast Weaknesses

All SwOS products support basic IGMP snooping, but not all of them allow running an IGMP querier on that switch. (e.g. the CSS106.) It is yet another of the consequences of the RouterOS Is RouterOS Everywhere design decisions that even when you’re running on hardware that can’t run an IGMP querier on the switch chip, you can still run a software querier under RouterOS instead. It’s a low-bandwidth operation, requiring very little CPU, leaving no good reasons to worry about the difference.

Another related weakness in SwitchOS is that it doesn't support MLD, the IPv6 equivalent to IGMP.

802.1X

SwOS lacks dot1x support entirely, even when the underlying SoC supports it directly, as with most of the dual-boot devices under RouterOS.

Ancillary Services

Much as with the IGMP Querier case, it is common to find situations where you need to run some ancillary service on the LAN, and the switch is a perfectly fine location for it. Good examples are:

NTP

Every LAN should have a local Network Time Protocol server rather than have every host go out to the Internet to sync their time independently. The LAN’s NTP server IP should be handed out with DHCP leases, and machines with static IP configs should point to it. While local DNS service may be too “heavy” to run on a switch, your LAN’s DNS should have common A records like “ntp.my-domain.internal” pointing to this NTP server.

None of the SwOS variations include an NTP server option. RouterOS does.

DHCP Server

Why would you ever want to run a DHCP server on a switch? Isn’t that a classic routing function?

The justification comes as a result of the continual blending of the L2 and L3 regimes in today’s increasingly smart switches. A classic example is with VLANs, where each VLAN sets up a distinct subnet range, which then means you need a separate DHCP server per subnet. What better place to do this than on the core switch that “owns” the VLANs? That isolates the VLAN distinctions to the single locus of each VLAN’s definition.

The alternative kinda sucks: create a trunk link up to the router and run these per-VLAN DHCP servers up there. It’s doable, but it smacks of router-on-a-stick designs, which are fine and useful, but that might not have been your intent. Part of the VLAN definition “escapes” to the router, violating separation-of-concerns design principles.

Certificate Authority

With everything going behind TLS and other asymmetric crypto walls, the need for a LAN CA is growing. If you don’t have a better place to put the LAN’s CA, the core switch is a perfectly fine place to do it. RouterOS’s CA feature is reasonably simple to use; easier than running manual openssl commands on a Linux box, at any rate.

This factor plays into the encryption discussion above.

Containers

One of the reasons RouterOS’s container feature is as stringently limited as it is is that it will run even on 32-bit ARM switches with 16 MiB of flash. Owing to these devices’ switch-class CPUs and lack of storage options, it ranges from foolish to impossible to run heavy containers on them, but within their limitations, you may be able to run a local ancillary service that has no better place to run on your LAN. The switch might be the only device that is running 24/7 on a sufficiently small LAN, for instance.

SwOS has no container runner.

VPN Termination

The small CPUs available in MikroTik switch hardware make them poor options as enterprise VPN concentrators, but in a home or SOHO context where you’re likely to see asymmetric Internet speeds, you can often run pure-software VPNs like WireGuard successfully. I did that for about a year sans problems since the switch only needed enough grunt to be able to fill the asymmetric upstream pipe.

One excellent reason to run a VPN on a switch is for secure management access when you lack the option of setting up a separate management LAN. Common cases where this comes up is when the switch is installed in someone else’s data center, or another similarly remote location.

RouterOS has many VPN technologies to choose from. SwOS has no VPN features at all.

RADIUS

Running a RADIUS server is a clear router function when used to terminate large numbers of PPPoE and VPN connections, but there are switch-adjacent use cases, too, such as the dot1x and management VPN use cases mentioned elsewhere in this article.

Automation

SwOS is meant to be administered wholly via its pointy-clicky web UI.

Not only does RouterOS offer multiple choices of front-end GUI, it offers multiple ways to automate back-end tasks:

  1. Scripting
  2. API calls
  3. SSH

The closest you can get to any of that on SwOS is ugly HTTP screen-scraping and automated URL submission. This does not constitute an “API” in any modern sense.

OS Network Stack

One of the key distinctions between “switch” and “router” class devices is whether I/O will be processed primarily by a dedicated switch ASIC or by a more general-purpose CPU. At this high level of abstraction, SwOS is meant for running purely atop switch chips, while RouterOS is meant primarily for running atop CPUs, with the option of delegating I/O down to a dedicated switch chip where possible.

Yet, even with SwOS, there are cases where we have no choice but to run tasks on the CPU. In such cases, RouterOS is always superior, primarily due to the fact that it is based on Linux kernel 5.6.3, containing one of the most capable TCP/IP network stacks in the world. By contrast, SwOS is based on some other, less capable OS kernel.

We can see evidence of this in multiple areas, but a few examples will suffice:

  1. No gateway IP. Whichever interface a request packet arrives by will be the path it will respond by. While this can work fine with simple LANs, it can make the device inaccessible over complicated routing schemes. The primary case where you see this is remote web management. You may end up needing to establish a VPN connection to the SwOS device’s LAN in order to get its web UI to respond in such cases.4

  2. Port-forwarding only. RouterOS gives you access to the Linux kernel’s destination NAT features, which go far beyond what SwOS can do.

  3. Software watchdog. If you enable the SwOS CPU watchdog, it activates when the switch stops running the web UI code, triggering a hardware power-cycle to get things running again. That's useful, but RouterOS' equivalent feature goes one level deeper: it can also trigger on ping failure, handling the case where the switch itself continues to run but it has lost L2 connectivity regardless.

Exceptions

There are a small number of cases where SwOS is objectively superior to RouterOS:

  1. Simpler VLAN setup, provided that your solution fits within the limitations of the SwOS web GUI. (Counterargument)

  2. The per-port “Lock On First” setting under the SwOS Forwarding tab has no direct equivalent under RouterOS. Alternatives:

    • scripting to poll the size of the FDB to catch the 0→1 size transition and then setting “/interface/bridge/port learn=no”
    • static MAC address assignment per port, with learn=no from the start

  3. Cheaper single-boot SwOS [Lite] products available.

Conclusion

I prefer RouterOS over SwOS even when given no dual-boot option. I will happily pay the extra for the likes of a hEX and reconfigure it as a switch than be forced into the limitations of SwOS by being a skinflint and buying a CSS106 instead.

License

This work is © 2024 by Warren Young and is licensed under CC BY-NC-SA 4.0

  1. ^ To be fair, there exist RouterOS-based switches that lack that ability, too. It’s mainly limited to the CRS3xx/5xx lines.
  2. ^ I’ve got a feature request into MT support that would let RouterOS read the SwOS configuration off the shared flash and convert it to RouterOS commands for you, but their response is that they wish to wait for more people to request it. This, then, is your action item for the day: if you also like this idea, file your own support request for this to add weight to mine.
  3. ^ This feeds back into the advanced VLAN features issue, since you need to choose MSTP over RSTP in some of these cases.
  4. ^ …which is all to the good due to SwOS’s lack of TLS support.