Putting a MikroTik CCR2004 at the edge of AS215855

My last post ended with the conclusion that the UDM-Pro is a fine home gateway as long as you keep BGP off it. That left an obvious question: what do you put BGP on?

For me the answer has always been Linux boxes running BIRD2. That works great, and it's still what runs at the PoP nodes in Ashburn and NYC. But I've been curious about MikroTik for a while. RouterOS keeps coming up in conversations with other small-ASN operators, and I wanted to understand why. So when a CCR2004-16G-2S+ showed up on eBay at a reasonable price, I grabbed it.

This isn't a "I replaced Linux with MikroTik" story. It's more of a "I put a MikroTik in front of everything to see what RouterOS is about" story.

Why the CCR2004

The CCR2004 is MikroTik's mid-range rack router. Four ARM64 cores at 1.7 GHz, 4 GB of RAM, 16 gigabit ethernet ports, and two SFP+ cages. It's a 1U box with redundant power supplies and no fans loud enough to hear from across the room.

Sixteen gig ports and two 10G SFP+ slots in a 1U box, for a couple hundred dollars used. That alone was enough to get my attention. The OS side of it helped too: full control over every interface, every route, and every filter. No controller sitting between you and the config. No "download, edit, upload" workflow for BGP. You type commands or click through Winbox and the router does what you told it to do.

The 4 GB of RAM also means it can handle full routing tables comfortably, which matters if you're running BGP with upstream peers that send you the full DFZ.

How it fits in

The CCR2004 sits at the edge of the network. One SFP+ port faces the WAN uplink, the other is a trunk port carrying all the internal VLANs down to the rest of the network, including the UDM-Pro which still handles UniFi adoption, cameras, and the WiFi side of things.

The SFP+ ports handle the two roles that actually need throughput. Everything else fans out over VLANs on that trunk: management, testing, Kubernetes, DMZ, IoT, and a couple of others. RouterOS makes VLAN config straightforward. You create the VLAN interface on the parent, give it an address, add it to an interface list, and write your firewall rules. No surprises.

BGP and the GRE tunnels

The CCR2004 terminates two GRE tunnels. One to the Ashburn PoP, one to NYC. These tunnels carry iBGP sessions to the BIRD2 instances running at each edge, and they're how inbound traffic for 2a0e:97c0:e61::/48 and 2602:f9ba:a10::/48 actually reaches the core. The edge routers announce the prefixes to their upstream transit providers, traffic arrives at whichever PoP has the best path, and it GREs back to the CCR2004.

Setting up the iBGP mesh itself was simple enough. Two peers, both inside GRE tunnels, both exchanging IPv6 routes. The CCR2004 handles it without visible effort. CPU sits around 4% under normal load.

Where it got weird was the filtering. In BIRD you write filters as structured blocks with if/then logic, pattern matching on prefixes, and it reads like a small programming language. RouterOS does filtering through numbered rules in /routing/filter/rule, closer to how you'd write firewall chains than how you'd write a route filter. Each rule is a separate entry with a matcher and an action, and they're evaluated in order.

It works, but it takes some rewiring if your muscle memory is BIRD's filter syntax. I spent more time debugging my filter rules than anything else in the setup. Things like matching on a prefix list or setting communities have their own syntax that doesn't map cleanly onto what I was used to.

Once the filters were right, the BGP side just worked.

RouterOS impressions

Coming from Linux, RouterOS is a different world.

The CLI is surprisingly powerful once you get past the syntax. The / path-based navigation, the print where filtering, the way you can chain commands. It's not bash and it's not BIRD's config language, but it has its own internal logic that rewards learning it properly. Tab completion is good. The built-in help is decent.

Winbox gets strong opinions. I use it for initial setup and for poking around interface stats, then switch to the terminal for anything I want to be repeatable.

Would I use RouterOS over Linux and BIRD for the PoP nodes? No, probably not. BIRD's config language is more expressive for complex filtering, and the ecosystem around it is exactly what I want for remote nodes I don't touch physically. But for a core router that terminates tunnels, runs a simple iBGP mesh, and enforces firewall policy, RouterOS is more than capable. It's a different tool for a different job, and I'm glad I finally have hands-on experience with it.

Monitoring

SNMP polling via NetPulse picks up interface counters, BGP session states, CPU, memory, temperatures, and fan speeds. The same dashboard that watches the BIRD2 nodes in Ashburn and NYC now watches the MikroTik. Watching mixed vendor gear from one place is one of the reasons I built NetPulse the way I did.

Where it stands

The CCR2004 has been running for about a week now and I'm happy with it. It does exactly what I wanted: sit at the edge, terminate the tunnels, run BGP, enforce the firewall, and stay out of the way. The UDM-Pro still handles the home network side of things, which is the role it was always better suited for.

I want to dig into RouterOS's scripting system for automated config backups, and I'm curious about what else this hardware can do now that I have a feel for the OS. But the routing and forwarding side has been solid from day one. If you've been running Linux and BIRD and you're curious what the MikroTik side of the world looks like, grabbing a used CCR2004 is a low-risk way to find out.