MikroTik RouterOS firewall (built-in on all routers) POST failure on startup: Diagnose & Fix

Topology deep dive: where this bites a Tier-2 WISP

Most of the MikroTik gear I run sits in small-town ISP backhaul: a CCR or RB-series box in a roadside cabinet feeding a cluster of access points across a Tier-2 town. The uplink is usually a leased fibre from a regional carrier (sometimes a BSNL or Railtel pipe, sometimes a local last-mile reseller), and the MikroTik is the demarcation between my network and the subscriber pool. When something breaks here, it does not break for one customer. It breaks for the whole sector, and the WhatsApp group lights up before I have even logged in.

The thing people miss about RouterOS is that the firewall, the routing table, and the bridge all live in one box on cheap hardware. There is no separate supervisor and line card to blame. When I touch this on a CCR2004 at a tower site, I keep a serial cable in the bag because the Ethernet management can drop the moment a config goes sideways. The cabinet has one 4G failover SIM on an LtAP, and that out-of-band path is the only reason I have not driven 60 km at 2 a.m. more than once.

On a boot or hardware fault the topology question becomes blunt: is this the only box at the site, or do I have a hot spare on the shelf? For my edge towers I keep a pre-staged hAP or RB5009 with a netinstall image ready. Swapping in 15 minutes beats waiting on an RMA that ships from the distributor in Mumbai a week later.

Configuration walkthrough I actually use

When a box will not boot cleanly, the first job is to get console output and a known-good image onto the device. RouterOS uses Netinstall over a direct Ethernet link with the box held in etherboot mode. This is the recovery I run from a laptop in the cabinet.

# On a box that still boots, capture state for the support ticket
/system resource print
/system routerboard print
/system health print
/log print where topics~"critical"

# For a dead box: hold reset, watch for etherboot, then Netinstall
# (Netinstall flashes a fresh image over a directly-cabled link)

If /system health print shows the PSU voltage or temperature out of range, I stop chasing software. A CCR pulling 12.0 V when it should read 24 V is a power problem, and no image reload fixes a failing brick.

Troubleshooting commands by platform

RouterOS is the platform here, but a backhaul link almost always has another vendor on the far end. When I am proving where a fault sits, I run the equivalent command on both sides of the link so the carrier cannot bounce the ticket back to me.

One field note: RouterOS /tool sniffer quick is gold for proving a problem to a carrier. I capture on the uplink, filter for the subscriber subnet, and screenshot the output for the ticket. A regional carrier NOC argues with a description; they do not argue with a packet trace timestamped from their own handoff.

India compliance and deployment notes

If you run a licensed ISP in India, a few rules touch this box directly. The DoT licence conditions and the CERT-In directions both expect time-synced, retained logs. RouterOS NTP plus remote syslog covers most of it, and I keep at least 180 days of logs off-box because that is the retention floor I work to. Set the clock to IST and lock NTP to a trusted source before you trust any timestamp in a dispute.

/system clock set time-zone-name=Asia/Kolkata
/system ntp client set enabled=yes
/system logging action set remote remote=10.20.0.5 remote-port=514
/system logging add topics=info,!debug action=remote

On the procurement side, this gear usually lands through a GeM tender or a distributor like Redington or a regional reseller. A CCR2004 runs roughly INR 55,000 to 70,000 depending on the USD-INR rate the week it ships; an RB5009 is closer to INR 18,000 to 22,000. There is no SmartNet equivalent on MikroTik, so my AMC budget goes into a shelf of cold spares rather than a support contract. For a 10-site WISP I keep two spare CCRs and a box of bidi optics; that is cheaper than downtime and far faster than an RMA. Under the DPDP framework, the subscriber data that transits this box (PPPoE usernames, session logs) is personal data, so I keep the syslog server itself access-controlled and inside the NOC, not on a cloud bucket with a guessable name.

A real deployment I did

Last monsoon I had a CCR at a tower site in a Tier-2 town near Hubli that went into exactly this kind of failure after a lightning-adjacent power event. The 4G failover held the subscriber sessions on a backup LtAP while I drove out. On the bench in the cabinet the box would paint half the boot then reset. Netinstall over a direct cable brought it back with a clean image, but /system health print still showed the PSU voltage sagging under load. I swapped in the cold-spare RB5009 I keep in the van, restored the exported config, and was back live in about 25 minutes. The original CCR went to the distributor on RMA two days later. Lesson I keep relearning: the spare on the shelf beats the cleverest recovery every single time.

Extended FAQ for field operators

Can I do this remotely without a tower visit? Usually yes, if you have an out-of-band path. I always keep a 4G failover or a serial-over-IP console at unmanned sites, and I run risky changes behind RouterOS safe mode so a mistake reverts itself instead of stranding me.

How does this differ on a CCR versus a hAP or RB5009? The CLI is identical across RouterOS, but the bigger boxes have hardware offload and real SFP cages, so some commands show extra detail. The small boxes are CPU-bound, so the same fix can behave differently under load. Test on the actual model in your rack, not a different one on the bench.

What do I tell the carrier when I open a ticket? Give them a timestamp in IST, your interface counters, and a packet capture from the handoff. Regional carrier NOCs (BSNL, Railtel, or whoever owns your last mile) move faster when you hand them evidence rather than a story.

How long does this take in practice? A planned change inside a maintenance window is 15 to 30 minutes including the rollback safety net. A genuine hardware failure is bounded by how fast I can get a cold spare into the cabinet, which is why I budget for spares instead of a support contract that does not exist for this platform.