MikroTik High CPU: Why RouterOS Throughput Drops

A MikroTik router that pegs one CPU core and forwards well below its published throughput is almost never defective hardware. It is nearly always a configuration that moved traffic from a path the device handles cheaply onto one it handles expensively. The fix depends entirely on which path the traffic ended up on, so the diagnosis has to come before the tuning.

Three paths, not one

RouterOS forwards a packet along one of three routes, and which one it lands on decides whether the board gets near its published figures. MikroTik’s own test tables show the routed side of that gap: an RB5009 does 811.2 kpps on the fast path at 1518-byte frames and 771.2 kpps with 25 IP filter rules loaded, while a hEX S drops from 148.4 kpps to 114.5 kpps once 25 simple queues are in the way. Traffic the switch chip handles is in a different category again, because it never reaches the CPU to be counted at all.

The switch chip. Layer 2 frames moving between ports on the same switch chip, within a configuration the chip can express, are forwarded in hardware. The CPU never sees them. This is why a device can move many gigabits between LAN ports while its routing figures suggest otherwise.

Fast path. Packets the CPU must handle, but which do not require the full processing chain, take a shortened route through the system. This is the path MikroTik’s headline throughput figures are measured on.

Slow path. Everything else. Connection tracking, firewall filter and mangle evaluation, queueing, IPsec policy matching, and accounting all live here. Correct, flexible, and far more expensive per packet.

FastTrack sits between the last two, and the distinction that matters is entry versus steady state. Connection tracking classifies the opening packets of a connection, a firewall rule then marks it with action=fasttrack-connection, and subsequent packets belonging to that connection are shunted onto the fast path instead of passing back through the tracking path. MikroTik documents the connection as staying fast-tracked until it is closed, times out, or the router reboots. Because not every packet of a connection can be fast-tracked, the fasttrack-connection rule is conventionally followed by an identical action=accept rule to catch the remainder.

What FastTrack bypasses, and why that matters

This is the part that turns a performance fix into an outage. FastTracked packets bypass the firewall filter, connection tracking, simple queues, queue trees parented to global, IP traffic-flow, IP accounting, IPsec, the HotSpot universal client, and VRF assignment.

Every one of those is a feature somebody deliberately configured. Enable FastTrack on a router with per-client bandwidth limits and the limits silently stop applying to fast-tracked traffic. Enable it where traffic-flow feeds an accounting or monitoring system and the graphs go flat while the link stays busy. Enable it in front of an IPsec tunnel and the tunnel breaks.

The inverse is equally common and is the usual cause of the “my router is slower than the box promised” complaint. Adding a simple queue, an interface-level bandwidth cap, or a mangle rule that has to see every packet forces traffic off the fast path. The router is not broken; it is doing the extra work that was asked of it, at the price that work costs.

So the first question in any throughput investigation is not “how fast is this CPU” but “which path is this traffic taking, and did I put it there on purpose”.

A diagnostic order

Confirm the load is real and find its shape. /system resource print gives overall CPU usage; the CPU submenu breaks it out per core. A single core saturated while the others idle is the signature of work that cannot be distributed, which is normal for a single heavy flow. All cores loaded evenly points at aggregate volume instead.

Attribute the load to a process. The Profiler under /tool profile shows CPU usage per RouterOS process and accepts a per-core view on multi-core systems. This is the step that turns guesswork into a specific answer, and the classification names the culprit directly. High networking points at forwarding work; high firewall points at rule evaluation; high management usually means something is polling the device hard, often SNMP or a monitoring system with an aggressive interval; high unclassified is a category MikroTik documents separately and is worth reading up on rather than guessing at.

Check whether the switch chip is still doing its job. If bulk local traffic that should never touch the CPU is showing up in networking, hardware offload has been disabled somewhere. Certain bridge and port properties are tied directly to switch-chip settings, and changing them can reset the chip or push forwarding into software. The interaction between VLAN filtering and hardware offload is the one that catches people most often; it is covered in VLAN filtering on RouterOS bridges.

Audit what was added since it was fast. Queues, mangle rules, traffic-flow, IPsec policies, and container workloads all move traffic off the cheap paths. Version control on configuration exports pays for itself the first time this question comes up.

Only then compare against the hardware ceiling. MikroTik publishes per-model throughput at several frame sizes. If the observed rate is close to the published slow-path figure for the board and the configuration genuinely requires slow-path processing, the answer is different hardware, not more tuning. The RouterOS FastPath and switch-chip sizer estimates the ceiling for a given tier and configuration, and the model-by-model figures are laid out in the MikroTik router buying guide.

Culprits worth checking early

A diagnostic tool left running. Torch, the packet sniffer, and a WinBox traffic graph left open all copy packets to the CPU. Sniffing on a busy interface can dominate the profile on a small board.

Logging to disk. Verbose logging with a disk target on a device with flash storage is expensive, and firewall logging on a rule that matches heavy traffic is the usual trigger. Logging to memory, or to a remote syslog target, costs far less.

Connection tracking table pressure. A device seeing large numbers of short-lived connections, or a host on the network generating a scan-like traffic pattern, drives tracking cost up sharply. Look at the connection count before blaming the rule set.

Rule ordering. RouterOS evaluates filter chains top to bottom. A long chain in which the rule that matches the bulk of traffic sits near the bottom does the same work as a short chain many times over. Putting the established/related accept rule first is the standard reason the default rule set is ordered the way it is.

DNS cache and resolver load. A router acting as the resolver for a large network with a small cache does meaningful work per query. This shows up as management-side load rather than forwarding load, which is why it is often missed.

Wireless on a combined unit. On a router that also serves Wi-Fi, wireless processing and forwarding compete for the same cores. A device that looks CPU-bound on routing may be CPU-bound on radio work.

Fixes in the order they should be tried

Remove diagnostic tooling that was left running and reduce logging verbosity. Reorder firewall chains so the highest-volume match is evaluated early. Move Layer 2 traffic back onto the switch chip by expressing the configuration in a form the chip supports. Introduce FastTrack only after confirming that nothing on the bypass list is in use, and scope it to the traffic that genuinely does not need queueing or accounting. Replace per-client simple queues with a queue design that survives fast-path forwarding where the requirement allows it. Then, if the load is still there, accept that the configuration costs what it costs and size the hardware accordingly.

What “high CPU” does not mean

A RouterOS device sitting at high CPU while forwarding at its published rate is working correctly, not failing. CPU utilisation is not a fault condition on its own; latency, drops, and throughput below expectation are. Check those first, and let the utilisation figure explain them rather than lead the investigation.

If the router in question is new, several of these traps are avoidable at build time rather than diagnosable afterwards. The configuration order that avoids most of them is in securing a new RouterOS box.