# MikroTik CCR2004 Review: A CPU Router With Switch-Like Ports

> Fourteen SFP ports for $595 — and every packet goes through the CPU

Canonical: https://everettkildare.com/blog/mikrotik-ccr2004-review-eight-months-in-production
Author: Everett Kildare
Published: 2026-07-23
Updated: 2026-10-31

The CCR2004-1G-12S+2XS occupies an unusual position: twelve SFP+ ports and two SFP28 ports in a 1U chassis, at a MikroTik suggested price of $595. It is easy to read that port list as a switch with a router attached. It is not. Every packet this box forwards is handled by its CPU, and once you plan around that, it is a capable edge and aggregation router.

Here is what the datasheet tells you, and what it implies.

## Specification

| | |
|---|---|
| CPU | AL32400, 4 cores, ARM 64-bit @ 1.7 GHz |
| RAM | 4 GB ECC |
| Storage | 128 MB NAND |
| Ports | 12 × SFP+ (10G), 2 × SFP28 (25G), 1 × GbE, 1 × RJ45 serial console |
| Switch chip | None with L3 HW offload (not in MikroTik's supported-device list) |
| Throughput | ~38 Gbps routed, 1518-byte frames, fast path (vendor test) |
| Power | Two AC inputs, 60 W max (31 W without attachments) |
| Cooling | Two fans; rated −20 °C to 60 °C |
| OS | RouterOS v7, licence level 6 |
| Suggested price | $595 |

## How it forwards traffic

The CCR2004 is **not** on the list of devices that support L3 hardware offloading. That list is built around Marvell switch chips in the CRS range and the larger CCRs — the 98DX3255, sometimes quoted for this model, belongs to the CCR2116. There is no `l3-hw-offloading` setting to turn on here, and no `hw-offloaded` route flag to look for.

Routing, bridging, firewalling and queueing all run on the four ARM cores. What decides your throughput is which path through RouterOS a packet takes:

- **Fast path.** An interface-driver shortcut that skips most of the Linux kernel. RouterOS uses it only while the box is close to unconfigured: no firewall rules, no active connection tracking, no simple queues or global queue trees, no IPsec policies, no VRFs, no IP accounting, and no sniffer or torch running.
- **Slow path.** Everything else. Each feature a packet must pass through costs CPU cycles per packet.
- **FastTrack.** Fast path plus connection tracking. Once a TCP or UDP connection is marked fast-tracked, its subsequent packets go the fast-path way and skip the firewall, connection tracking, simple queues, global queue trees, IPsec, IP accounting and traffic-flow.

## MikroTik's published test results

MikroTik publishes RFC 2544 results for this model (all ports, 0.1% loss tolerance). The routing rows tell the story:

| Routing configuration | 1518 B | 512 B | 64 B |
|---|---|---|---|
| None (fast path) | 38,116 Mbps | 23,717 Mbps | 6,071 Mbps |
| 25 simple queues | 22,458 Mbps | 7,688 Mbps | 1,025 Mbps |
| 25 IP filter rules | 14,304 Mbps | 4,854 Mbps | 636 Mbps |

Bridging is in the same table and is also a CPU job: about 38.5 Gbps at 1518 bytes on the fast path, falling to 21.4 Gbps with 25 bridge filter rules.

Three things stand out. First, frame size matters as much as configuration: at 64 bytes the fast path manages roughly 11 million packets per second, about 6 Gbps, so "38 Gbps" is a large-packet figure. Second, 25 firewall rules cut large-frame routing to about 14 Gbps, and to roughly a fifth of fast-path at 512 bytes. Third, MikroTik notes that other configurations will likely do worse — these are best cases.

My reading of those numbers: with a realistic edge firewall and no FastTrack, plan for low double-digit gigabits on large packets and considerably less on a mix of small ones. That is still a lot of router for the money, but it is not fourteen ports of line rate.

> [!WARNING]
> Nothing in this box forwards in hardware. The fast-path figure only applies to a router with no firewall rules, no connection tracking and no queues. Size it against the filter-rule and queue rows, and against your real packet-size mix, not the headline number.

## Getting the CPU back: FastTrack and notrack

For a stateful edge, FastTrack is the main tool. The standard pattern from MikroTik's packet-flow documentation is a fasttrack rule for established and related connections, followed by an identical accept rule:

```routeros
/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related \
    comment="fasttrack established/related"
add chain=forward action=accept connection-state=established,related \
    comment="accept established/related"
```

The accept rule is not redundant. Only TCP and UDP can be fast-tracked; everything else still needs accepting. The first packets of each connection still traverse the full firewall, so your policy is enforced at setup — it is the bulk of the flow that skips it.

Verify it is working rather than assuming:

```routeros
/ip firewall connection print
/interface print stats-detail
```

Fast-tracked connections carry a fast-tracked flag in the connection table, and `stats-detail` shows whether interfaces are using fast path.

Two caveats matter in practice. Fast-tracked traffic is invisible to queues, so FastTrack and per-flow shaping work against each other — exclude shaped traffic from the fasttrack rule. And fast-tracked packets bypass IPsec policies, so traffic meant for a tunnel must be accepted before the fasttrack rule or it leaves unencrypted.

Where you do not need state at all — east-west traffic between your own prefixes, say — exempt it from connection tracking in the raw table:

```routeros
/ip firewall raw
add chain=prerouting action=notrack src-address=10.0.0.0/8 dst-address=10.0.0.0/8
```

Connection tracking defaults to `enabled=auto`: off until the first firewall rule is added. On a pure transit router with no filter rules, leaving it there keeps you on the fast path.

## What it does well

**Port density for the money.** Twelve 10G ports plus two 25G uplinks in 1U at this price is hard to match, and it is the reason to look at this box at all.

**A real routing stack.** RouterOS v7 can split routing work across processes, with BGP input and output placed per peer through `input.affinity` and `output.affinity` in `/routing/bgp/template`. On a four-core CPU that matters, and `/routing/stats/process/print` shows what each task is using. Whether it suits your table sizes and peer count is something to test, not assume.

**IPsec acceleration.** MikroTik's IPsec documentation lists the AL32400 with hardware acceleration for AES-CBC, AES-CTR and AES-GCM alongside SHA-1 and SHA-2 hashing. Remember the FastTrack interaction above.

**Dual AC inputs and ECC memory** are welcome at this price point.

## What it does badly

**It is a router, not a switch.** Bridging between ports goes through the CPU and shares it with everything else. If you need wire-speed switching between many 10G ports, a CRS-series switch with L3 offload is the right tool, with the CCR above it.

**Throughput is configuration-dependent and quiet about it.** Add a firewall rule, a queue, or a sniffer session and the box leaves the fast path without telling you. Benchmark the configuration you will actually run.

**Support is self-service.** In my judgement, RouterOS documentation covers syntax well and behaviour less consistently; teams used to a vendor TAC should factor in that they are not buying one.

## Optics

Check every link after installation:

```routeros
/interface ethernet monitor sfp-sfpplus1 once
```

Look at `sfp-temperature` and `sfp-rx-power`. A module running hot or a weak receive level is far easier to deal with on day one than after a flapping link.

## Who should buy it

**Yes, if:** you need 10G port density on a constrained budget, your team is comfortable with RouterOS, and your traffic profile lets you run a light firewall with FastTrack — or your heavy stateful inspection sits on a separate device. As a BGP edge or aggregation router it is good value.

**No, if:** you need deep stateful filtering or per-flow shaping at multi-gigabit rates, wire-speed switching across many ports, or vendor support with an SLA. Also no if nobody on the team knows RouterOS — the learning curve is real, and the failure modes are quiet.

The most common mistake with this class of hardware is reading the port list as a promise. The vendor's own table shows the device delivering its headline figure only when it is barely configured.

**Verdict: 4 / 5.** Outstanding value, provided you size it as a CPU router and use FastTrack deliberately.

## Sources

- [MikroTik · CCR2004-1G-12S+2XS](https://mikrotik.com/product/ccr2004_1g_12s_2xs) — CPU, RAM, storage, ports, two AC inputs, 60 W / 31 W power, two fans, operating range, RouterOS licence, $595 suggested price, and the RFC 2544 routing and bridging test results.
- [L3 Hardware Offloading](https://help.mikrotik.com/docs/spaces/ROS/pages/62390319/L3+Hardware+Offloading) — the list of devices that support L3 offload; the CCR2004 is not on it, and the 98DX3255 is the CCR2116's chip.
- [Packet Flow in RouterOS](https://help.mikrotik.com/docs/spaces/ROS/pages/328227/Packet+Flow+in+RouterOS) — fast-path conditions, what FastTrack bypasses, the TCP/UDP limit, the fasttrack/accept rule pair, and the verification methods.
- [Connection tracking](https://help.mikrotik.com/docs/spaces/ROS/pages/130220087/Connection+tracking) — the `enabled=auto` default and raw-table `notrack` exemptions.
- [IPsec](https://help.mikrotik.com/docs/spaces/ROS/pages/11993097/IPsec) — AL32400 hardware acceleration, and fast-tracked packets bypassing IPsec policies.
- [Routing Protocol Multi-core Support](https://manual.mikrotik.com/docs/user-guides/routing-and-networking-protocols/routing-protocol-multi-core-support/) — RouterOS v7 multiprocess routing, BGP `input.affinity`/`output.affinity`, and `/routing/stats/process/print`.