pjhtech Tools
MikroTik · RouterOS v7

MikroTik Route Commands: Routing Tables and Policy Rules

Quick answer #

Read /ip/route for IPv4 routes, /ipv6/route for IPv6, and /routing/route for the richer routing view. Then inspect /routing/table and /routing/rule if the packet should use a custom table. A correct default route in main does not establish which table a forwarded client packet actually uses.

Scope: RouterOS v7 on RouterBOARD, CCR, CRS running RouterOS, or CHR where the relevant feature exists. Not SwOS. Output fields depend on release and hardware. Uses v7 routing table and rule menus; v6 routing-mark recipes are not interchangeable.

Commands #

wan2 is an example custom table. The documentation prefix is an exact route-table query, not a longest-prefix lookup for an arbitrary host.

Commands
RouterOS v7 · RouterOS v7 terminal; absolute menu paths

Read-only

Replace these example values: 0.0.0.0/0.

/ip/route/print detail where dst-address=0.0.0.0/0
Read-only
/ipv6/route/print detail where dst-address=::/0
Read-only

Replace these example values: 203.0.113.0/24.

/routing/route/print detail where dst-address=203.0.113.0/24
Read-only
/routing/table/print detail
Read-only
/routing/rule/print detail
Read-only

Replace these example values: wan2.

/ip/route/print detail where routing-table="wan2"
Read-only
/ip/firewall/mangle/print detail
Read-only
/ip/firewall/mangle/print stats

Read the result #

Separate the configured gateway from the resolved forwarding next hop. The detailed route view can show whether a route is active and how its next hop resolves. Multiple candidates for one prefix do not mean that all candidates forward packets. Use the printed flags and attributes rather than assuming the first displayed line wins.

Policy routing adds another selection step. A routing rule can select a table based on packet attributes, while mangle can assign a routing mark. MikroTik documents mangle priority when its marked lookup can be resolved. Review both mechanisms when a table looks correct but client traffic still exits through the wrong WAN.

A lookup-only-in-table rule and a lookup rule have different failure behaviour. The former does not provide the same fallback to another table. This distinction matters when a backup path is expected to work after the preferred next hop disappears.

Investigate one destination #

Start with one affected client and one destination, not a general statement that the Internet is broken. Record the client's source address and ingress interface. Identify the policy rule or mangle decision that should apply, then inspect routes in that specific table. Check next-hop resolution separately from the route's existence.

Compare a client-originated test with a router-originated test only after documenting their source addresses. They need not traverse the same policy and firewall path. A successful router ping is useful evidence, but it cannot stand in for the failed application flow.

Pitfalls #

Avoid changing distance, scope and target-scope together. That removes the ability to tell which dependency was broken. Capture the current candidates first and change only the intended dependency in a planned window.

For large routing tables, use a specific prefix or table filter instead of dumping every route into a terminal session. If policy behaviour changes only when FastTrack is disabled, continue with the existing FastTrack guide rather than rewriting all routing rules.

Sources

Documentation reviewed: 8 October 2026