Motivation

MikroTik’s product line purposefully blurs the old distinction between switches and routers, but it is a mistake to believe this means they’re interchangeable. While there is considerable value in choosing to run an operating system called “RouterOS” on a switch, it is generally a mistake to try treating a device built to be a switch yet called a “Cloud Router Switch” as a router merely because it has some confusing branding associated with it.

It is best to let your switches switch and your routers route.

Switches Have a CPU to Run Auxiliary Services

Consider this simple configuration:

thickness = 0.01
color = 0x454545
fill = 0xF0F5F9

RT: circle "Internet" "router" fit
    arrow 0.25
LC: ellipse "core" "switch"

PORTS: [
  down
  box "1" small width 0.15 height 0.1
  box "2" small same
  box "3" small same
  box "4" small same
] with .w at LC.e + (1.1, 0)
SW: box "room" "switch" height PORTS.height with e at PORTS.w
    right
FP: box width 0.15 height SW.height with .e at SW.w
    line from previous.n to previous.s invis "SFP+" small aligned
    arrow from LC.e to FP.w

PC: box "local" "PC" radius 0.05 fit with .w at PORTS.e + (0.25, 0)
    arrow from PORTS.e + (0, PORTS.height / 8) to previous.w

This is a common arrangement. The room switch takes in a single fiber connection back to the LAN core and fans it out to provide four in-room copper ports, which saves us from needing to pull multiple copper runs back to the core. If all five ports on the room switch run at 1 Gbit/sec, and you’re using gigabit SFP modules for this run, then any single host in that room can dominate the entire bandwidth back to the core. If two hosts try that, they will split the available bandwidth between them. For this reason, we may prefer to use 10G here, giving all in-room hosts the illusion that they’ve got a dedicated path back to that core.

The point is, the amount of CPU power in that room switch doesn’t affect any of this because the in-LAN communication decisions all occur in hardware, within a purpose-designed chip at its core. This design concept is called line-rate switching to contrast it with routers, which generally cannot achieve that under all conditions.

While there are ways to bottleneck a modern switch chip¹ the designers avoid it by limiting the task scope to what can be done purely in hardware, at line rate. Even a dumb-as-rocks switch chip will provide an N-way switching fabric with MAC learning. Going up the scale, you may also get other L2 niceties like QoS, VLANs, and IGMP snooping, all without impacting the goal of having line-rate switching under all conditions.

If these boxes have a CPU in them at all, it is to do on-boot configuration of the switch chip, plus possibly to run the most basic of web UIs. It is not there to provide any router-like facilities.

The better class of switch chips edge into L3 territory to varying degrees, but even at the high end that does not magically make a device into full L3 router. The term “L3 switch” is marketing-speak owing to the industry’s tendency to blur lines. Outright eliminating those lines carries costs, primarily in CPU power and memory. MikroTik switches have significant amounts of both, but generally not enough to make them into proper routers. That leads us to the sensible paths pointed out in the companion article “Run RouterOS on Your Switch.” What concerns us here is the tendency to exceed these bounds out of a desire to have the power of a full L3 router at the cost of a bargain-basement switch.

The original purpose for having CPUs in switches was to run a small OS such as MikroTik’s own SwOS, which has features barely sufficient to run a pretty web UI. There’s an old joke: the optimist sees the glass half-full, the pessimist sees it half-empty, and the engineer tells you the glass is twice as big as it needs to be. Thus these CPUs: they are downsized until they are barely adequate for the minimal purposes to which they are put. To do otherwise is to bring the BOM cost up to no useful end.

And yet it is the nature of the silicon industry to keep giving us more power for the same price. What shall we do with this largess?

Why, add “router” class features to our switches, of course!

And thus we begin to get into trouble.

Consider the CRS328-24P, near the top end of the CRS3xx range and consequently expensive on the scale of other MikroTik equipment. Although it only gives us a single-core 800 MHz CPU, that’s plenty for running WebFig, a basic SSH server, and a few minor background services such as NTP.

Now contrast the 2025 hEX S where roughly one-seventh the price gets you roughly a quarter the port count. Good deal, yes?

But hark! Why does the cheap little router have well over twice the CPU power as the big core switch?

Simple: because it’s a router, not a switch!

Routers Use the CPU to Route Packets

Like many other network operating systems, RouterOS is based on Linux because that allows MikroTik to take advantage of decades of FOSS development. That is not to say that RouterOS is just another Linux distro with a proprietary candy shell poured on top, but it does mean RouterOS gets a lot of its power by delegating tasks to the underlying OS kernel.

And that takes CPU grunt!

RouterOS is smart about offloading tasks to the underlying switching hardware when it can, avoiding loading down the CPU. There is a great document on the RouterOS help site which, if heeded, can guide you in limiting your feature use to what a given switch chip can do in silicon. Anything else costs CPU power. If you can restrict your use cases to tasks the switch chip can handle, you can treat a device designed as a router as an uncommonly smart switch, saving the CPU power for something else, such as running containers.

That said, devices classed as “routers” tend not to have the best switch chips. Traffic is more likely to end up crossing the CPU than if you had selected a dedicated switch.

Blurring the Lines

The discussion so far has discussed the switch chip and CPU as if they were separate things, but the silicon industry loves consolidating functions. Properly speaking, many devices in MikroTik’s lineup have but a single core IC called a “system on chip,” or SoC. These combine a small-ish CPU core with switching fabric and other facilities, simplifying implementation and saving costs.

RouterOS tends to get more out of that CPU than its competitors, who use it merely to run the web UI, maybe an SSH server. This is where we can get into trouble: because RouterOS on a “switch” class device is the same RouterOS they put on a proper “router,” newbies to the RouterOS ecosystem will often try to treat a switch as a router, then come crying to the forum that performance is terrible.

Yeah, we know. You’re holding it wrong.

Let your switches switch, and your routers route.

Having It Both Ways

There is an upper limit to that philosophy: at the high end, you don’t have to choose.

MikroTik has a class of devices designed to serve both ends, which they call the CCR line. These combine a high-end switch chip and a strong CPU in a single package. The tradeoff is that this is more expensive than doing either separately.

The big-boy vendors have been going down this path for a long time, and so you will find transplants who look at the RouterOS feature set and the low cost of MikroTik gear and expect to get a better deal than is actually being offered. Competing products may cost many times what the superficially equivalent MT one does, and that doesn’t go purely into profit, rampant overhead, and Silicon Valley salaries. Some of it does actually go into performance.

If you are expecting Cisco/Juniper/Arista-like performance on a TPLink budget, you may need to step up within MikroTik’s line in order to to split the difference properly.

There is another path open to those who can let go of the desire to have both functions in a single box. At the low end, a strong dedicated switch cabled to a strong dedicated router will vastly outperform a single device that tries to do both for the same cost. Each device focuses on its competency and shuttles packets to the other as necessary, offloading work to the other. For simple setups, this doesn’t even require tricky configuration; the rules baked into the Ethernet and TCP/IP protocol suites suffice.

Above, we used the CRS328-24P and 2025 refresh of the hEX S as examples. The device designed to be a router has a competent but unspectacular switch chip in it, while the purpose-designed switch has one of the better switching feature sets in MikroTik’s lineup, but a crappy CPU. Each will do a terrible job of trying to fill the other’s role: the cheap router will run circles around the expensive switch when it comes the routing, and the big switch will kick the router’s ass on pure L2 packet shuttling tasks. By running a single fiber cable between the two, you get strong performance on both tasks, for cheap.

Because MikroTik does not produce every imaginable product combination, you might not even have a choice in the matter. While every product in their CCR line will handily beat a hEX in pure routing, none of them have as many ports as a CRS328-24P, and where they do provide PoE, it is on a subset of their ports.

There is a potentially infinitely-fine grayscale continuum here. We may illustrate it by studying a few stand-out products…

The Router That Thinks It Is A Switch

The PoE version of the RB5009 is designed as a router first, but it has full active PoE output on all ports, traditionally a switching function. It is a perfectly valid use to reconfigure this device from stock and treat it as an uncommonly smart PoE switch.

At the same time, there are more powerful switch chips in MT’s lineup. For certain tasks, you may find yourself wishing for a CCR or a classic switch+router pair.

The Switch That Thinks It Is A Router

If we flip matters around one-eighty, we find the CRS418, a rare beast that is both a competent router and a strong switch. It is the first in the new CRS4xx line, which means it has strong switching abilities — in this case including PoE — but it also has enough CPU grunt to take roles that used to be given to the CCR line.

Contrast the CRS320, at roughly the same cost. The tradeoff is that it has much better PoE but a much weaker CPU. This is a switch first; pressing it into a routing role is likely a network engineering design error.

License

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

1. ^{^} Hardware QoS, configurable rate-limiting, failed speed negotiation…