The lens I route by
How I think before I touch a route. These are the habits that decide the design — and the reason the routing holds when something fails.
- 01
Failure-mode first
I design every route assuming a link will die — the failover path is the first thing I build, not the last. A single uplink is a single point of failure until it has a backup that takes over on its own.
- 02
Read the table, don’t guess it
The routing table is the truth. Route flags, distance, and scope tell me exactly which path a packet takes, so I debug by reading what the router actually decided — never by assuming what it should.
- 03
Protocol by purpose, not by habit
Static where the topology is stable, OSPF where it changes on its own, policy routing where the path is a deliberate choice. The job picks the tool — never a reflex, never one protocol everywhere.
- 04
Narrowest match wins — design the table
Most-specific routes and recursive next-hops are deliberate instruments, not surprises. I shape the table so the right path is the inevitable one, then let RouterOS resolve it the way it always does.
What I run in production
The routing jobs running live on RouterOS — failover, policy routing, static routing, and single-area OSPF.
Command by area
1 Learning · 2 Aware · 3 Confident · 4 Fluent · 5 Teach
- deployed leaf
- knowledge ahead of deployment
- deployed ahead of the textbook
Routing Concepts (4)
- Route FlagsTeach
- Introduction to Dynamic RoutingTeach
- Gateway Reachability & Route DistanceTeach
- Scope & Target-ScopeConfident, knowledge ahead of deployment
Static Routing (6)
- Default RoutesTeach
- More-Specific RoutesTeach
- Point-to-Point AddressingTeach
- ECMP (Equal-Cost Multi-Path)Fluent
- Recursive Next-HopFluent
- Gateway Forcing over InterfaceConfident
Policy Routing (2)
- Routing MarksTeach
- Policy RoutingFluent
OSPF (11)
- Router TypesAware, knowledge ahead of deployment
- OSPF Mechanics (Hello, LSA, Neighbor States, DR/BDR)Fluent, deployed ahead of the textbook
- Interface CostFluent, deployed ahead of the textbook
- Network Types (Broadcast / NBMA)Fluent
- External Route Distribution (Type-1 / Type-2)Aware, knowledge ahead of deployment
- Multicast IssuesConfident, knowledge ahead of deployment
- Virtual LinksAware, knowledge ahead of deployment
- Network AreasAware, knowledge ahead of deployment
- Stub / NSSA / Area RangesAware, knowledge ahead of deployment
- Routing FiltersAware, knowledge ahead of deployment
- SPF AlgorithmAware
Grouped by curriculum topic, deepest first. Solid indigo runs to the depth I deploy in production; the hatched caps are the multi-area OSPF depth I've studied past my single-area deployment; the two notches are the OSPF mechanics I run a notch past the exhaustive theory.
Dual-WAN failover that survives an ISP dropping.
Two uplinks, one set as primary and one as backup. When the primary stops answering, the router’s health check (check-gateway) pulls it and the next packets exit through the backup — no script, no manual switch.
Policy routing that sends the right traffic out the right link.
A session is classified once at its start and stays pinned to its uplink for its whole life — latency-sensitive traffic out one ISP, bulk out the other.
Static routing that holds the daily baseline.
Routes resolve the way RouterOS actually picks them — most-specific wins — so traffic lands where you intend. Underneath: default routes, more-specific overrides, recursive next-hops that resolve through another route, and equal-cost load sharing (ECMP).
Single-area OSPF that converges and recovers on its own.
Neighbors discover each other, elect a designated router — the DR/BDR pair — and I catch the MTU mismatch that would otherwise stop two routers from forming the OSPF adjacency. The result is dynamic routing that reroutes around a topology change on its own — the network recomputes its own paths, no config edit from me.
OSPF cost design that steers the path you intend.
Per-interface cost tuning so traffic prefers the link you chose, not the one the defaults happened to pick.
The RouterOS mechanisms, named
- Failover
- check-gateway · recursive next-hop · route distance
- Path choice
- mark-connection → mark-routing · per-flow routing marks
- Load sharing
- ECMP — equal-cost multi-path, per source/dest flow
- Table design
- most-specific match · default + override routes · scope / target-scope
- Point-to-point
- /32 addressing with the RouterOS network idiom
- OSPF
- single-area adjacency · DR/BDR · per-interface cost · NBMA / point-to-multipoint
The primitives a RouterOS routing job actually turns on — each one I run, not just know.
Watch a link fail
Two uplinks into one router. Drop either one and the active path reroutes through the survivor — the same mechanism I deploy. Toggle a failure below.
Choose an uplink failure scenario
Want just the failover, to keep or to share? It lives on its own here — a recursive-routing simulator you can bookmark. Open the standalone simulator →
The frontier — exactly where the line is
Where routing is deep, where it is studied, and where the edge sits. Named precisely, because on routing the precision is the credibility.
- In production
Dual-WAN failover, policy routing, recursive static routing, and single-area OSPF — run and supported in the field, the daily baseline.
- Studied, not yet deployed
Multi-area OSPF — areas, NSSA, router types, virtual links: exam-verified at MTCRE (94%), the theory solid. Deployed as an engagement calls for it, not before.
- The frontier
Carrier-scale inter-networking — MPLS/VPLS and BGP at policy scale. Concept-aware, not deployed: the named edge I am climbing, stated plainly rather than implied.
Where the routing comes from
The foundation was laid by hand, on paper, before it was ever in production.
- Foundation
Learned routing by hand — Moscow, 2016.
MTCNA at a Moscow training center: route tables filled in by hand on paper before a single packet moved. The fundamentals built deliberately, not skipped.
- Routing engineer
MTCRE, Moscow, 2016 — the advanced routing lab.
The routing-engineer certification under a MikroTik trainer in person — static routing, policy routing, and OSPF taken past the basics in a hands-on lab.
- In production
Run in the field ever since.
Dual-WAN failover, policy routing, and static routing carried in production engagements for years — proven where it runs, named honestly where it does not.
Routing that holds — every flow on the link you chose, and a path that reroutes itself when one fails. That is the whole of the brief.
Where routing connects
Routing rarely ships alone. The domains it depends on, and the exams that verify the depth.
- Related domainFirewall & NATThe traffic-marking rules (mangle marks) policy routing depends on, and the NAT that sits beside every uplink.
- Related domainAddressing & DHCPThe plan every route sits on — the subnets and gateways each next hop resolves against.
- Related domainFundamentals & recoverySafe Mode and an off-box backup before any route change — so a bad route rolls back instead of cutting me off.
This is the issued MTCRE certificate — the routing-engineer exam behind the claims, shown whole.
Certificate ID 2505RE5380 — cross-checkable on mikrotik.com.
Bring your routing problem — failover, policy routing, or OSPF on RouterOS — and I will scope it.
Scope my routing problem