RouterOS fundamentals I teach and use to rescue dead boxes

The habits I drill into every student and set on every box before it carries a packet. The basics are boring on purpose — this is how they stay that way.

• 01

  Lock the front door on day one

  Before a box carries a single packet, its users, its services and its neighbour-discovery are pinned to the side of the network I manage it from — nothing answering the wide world that does not have to. The management plane is the first thing I close and the last thing I open: I would rather add an access rule back on purpose than find out months later what I left listening.

• 02

  Know the way back first

  I never touch a remote box without an exit already in place — a backup taken off the device, the reset-button windows in muscle memory, netinstall ready to go. Recovery is the first thing I set up, not the thing I improvise once the box is already dark and a plane ticket is the only other option.

• 03

  Change under a net

  Anything that could lock me out goes in under Safe Mode — provisional first, committed only once I have proven I did not just cut the line I am standing on. Drop the session and the box rolls the change back on its own. It is the difference between a mistake and an outage.

• 04

  Backup is not export

  A sealed, device-tied snapshot and a portable, readable script are two different tools for two different jobs: one restores this exact box, secrets and all; the other I can read, diff and re-run onto another. And the export default is version-dependent. RouterOS 6 wrote secrets into an export in clear text unless told otherwise, which is how the forums filled with rookies’ leaked credentials, pasted straight out of a config. RouterOS 7 flipped it to hide secrets by default, which broke migrations and long-trusted backup schedulers that had always captured them. Knowing which tool and which default the moment needs is half of config management.

The rules I teach with a story attached, because I earned them the hard way — not from the manual, from the recovery afterwards.

• The upgrade rule I never break

  Never flash a PoE chain in parallel.

  I once kicked off a RouterOS upgrade across a set of PoE-chained RouterBOARDs at the same time — the smart move, or so it looked. The device powering the chain finished first and rebooted itself to apply the new version, and the instant it did it cut power to everything downstream of it, mid-write. The powered devices came back to half-flashed NAND: bricked, all of them, in one keystroke. Since then the rule is absolute, and I teach it the same way: stagger the upgrades, do the powered-downstream devices before the one that feeds them, and let each come fully back before you touch the next. On a chain you are never upgrading one box — you are upgrading its power supply too.

• The net that saved a boat ride

  Safe Mode handed me a mistake back — from another continent.

  I was on a wireless-ISP customer’s network over a VPN, a continent away, rotating the encryption key on a point-to-multipoint nv2 link — a long-range 5 GHz radio out on a remote tropical island. Get a key rotation wrong on the far side of a wireless link and you drop it, and there is no second way in: the fix would have been a boat or a helicopter and a pair of remote hands that do not exist out there. But the change was in under Safe Mode, so when the link fell and my session with it, the radio quietly rolled the change back and came up on the old key. I reconnected as if nothing had happened. RouterOS 7.18 later made Safe Mode scriptable — an auto-revert you can build straight into a script — which turns it into a deterministic fail-safe for automated and AI-driven changes, exactly the kind of guardrail an unattended change most needs.

  My open RouterOS safe-mode reference on GitHub (tarikin) ↗

The fundamentals stopped being basic for me the summer I had to teach them. You cannot teach what you only half-know — a room of beginners finds every gap in an afternoon.

• The classroom that made me teach it

  A month building an MTCNA course by hand, for a cohort in Vietnam.

  I founded the first authorized MikroTik training center in Vietnam, and to run it I spent more than a month hand-building the MTCNA material — every bring-up, every recovery, every quirk, written out so a beginner could follow it. A room of Vietnamese beginners taught me something no manual would — stay in ASCII at the console; diacritics and other non-Latin input can misbehave the moment you are inside the CLI, and a class learns that the hard way in an afternoon. That is where the fundamentals became reflex.

• The fluency I mistook for common sense

  Teaching showed me the basics I take for granted are earned fluency — and one talk showed me how fast a small one, gotten wrong, costs you.

  The tricks had become muscle memory — mac-telnet in when the IP is gone, RoMON to a box with no address, the reset-hold windows read by feel — things I had stopped noticing I knew, until a beginner’s “obvious” question showed me the obvious answer was fluency I had paid for without noticing. Moscow, 2017, barely a year in, taught me the flip side. I rebuilt a wireless-audit case in WinBox screenshots for a talk and missed one fundamental: I had captured them under a full-permission user, so fields a read-only account would have greyed out were editable. The senior engineers spotted it in seconds, and the whole story lost its weight — one basic, wrong, and the people who know the platform stop believing you. That is why I treat the fundamentals as sacred: they are the fluency I trust most, and the first thing an expert checks.

The fundamentals are the part nobody notices until they break. I keep them boring on purpose — every box reachable, recoverable, and the same one I would hand a student.

Bring the box — a fresh deployment, a fleet upgrade you want done without bricking it, or a device that will not come back. I will scope it.