NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: IP → Routes
2. CLI: /ip route print — active only: /ip route print where active
3. Best single command: /ip route check 8.8.8.8 (returns chosen gateway + interface)
4. Detail: /ip route print detail where dst-address=0.0.0.0/0

Gotchas & notes

• Read the flags: A active, D dynamic, S static, C connected, X disabled, I inactive. Only A routes forward traffic; a static route without A has an unreachable gateway.
• /ip route check is the fast answer to 'which way does this go' and accounts for distance and ECMP.
• With ECMP (two routes, same distance) RouterOS 7 does per-flow hashing; check shows one of the paths, not all.

Steps

1. GUI: Dashboard → Network → Routing widget, or Network → Static Routes for configuration only.
2. CLI (FIB — what is really used): get router info routing-table all
3. Lookup a destination: get router info routing-table details 8.8.8.8
4. Kernel-level check: diagnose ip route list

Gotchas & notes

• Network → Static Routes shows configuration, not the routing table. A route listed there may be inactive. Use get router info routing-table all to see what is installed.
• The route codes match Cisco convention (C connected, S static, O OSPF, B BGP), which makes this output familiar if you came from IOS.
• Per-VDOM: run the command inside the correct VDOM or you get the management VDOM's table.
• Policy routes (Network → Policy Routes) are evaluated before the routing table and do not appear in it — a packet can ignore the entire table you are reading. Check diagnose firewall proute list.

Steps

1. The UniFi UI has no routing-table view.
2. SSH to the gateway → ip route show (or ip route get 8.8.8.8 for a specific lookup).
3. For multi-table/policy routing: ip rule show then ip route show table <n>.

Gotchas & notes

• ip route get <ip> is the direct equivalent of MikroTik's route check and answers the question in one line.
• UniFi installs policy-routing rules for features like WAN failover and VPN policy routes, so ip route show alone can be misleading — check ip rule show too.
• Read-only: never change routes from the shell, since the next provision reverts them.

Steps

1. show ip route — or for one destination: show ip route 8.8.8.8
2. The forwarding truth: show ip cef 8.8.8.8
3. Per-VRF: show ip route vrf MGMT
4. Summary: show ip route summary

Gotchas & notes

• show ip cef beats show ip route when they disagree, because CEF is what actually forwards packets. A route/CEF mismatch is a real (if uncommon) failure that a show ip route alone will never reveal.
• show ip route 8.8.8.8 performs a longest-prefix lookup and prints the winning route plus its source — much better than eyeballing the whole table.
• The codes legend at the top matters: administrative distance and metric appear as [110/20] (distance/metric). Two routes to the same prefix means the one with lower distance won.
• A missing default route shows as Gateway of last resort is not set at the top — read that line first.

Steps

1. GUI: Network → Virtual Routers → <router> → More Runtime Stats → Routing → Route Table.
2. CLI: show routing route — filter with show routing route destination 8.8.8.8
3. Definitive lookup: test routing fib-lookup virtual-router default ip 8.8.8.8
4. FIB: show routing fib

Gotchas & notes

• More Runtime Stats is again the hidden GUI location — the Virtual Router config page does not show the live table.
• test routing fib-lookup is authoritative and includes policy-based forwarding effects; show routing route does not.
• Policy-Based Forwarding rules (Policies → PBF) override the routing table entirely and are invisible in it, exactly like FortiGate policy routes.
• With multiple virtual routers, always pass virtual-router <name> or you are reading the wrong table.

Steps

1. GUI: Diagnostics → Routes — shows the IPv4 and IPv6 tables with flags and interfaces.
2. Gateway health: Status → Gateways.
3. CLI: netstat -rn or route -n get 8.8.8.8

Gotchas & notes

• Status → Gateways is the first place to look, not the route table: a gateway marked *Offline* by the monitor removes its routes, which explains most sudden routing changes on pfSense.
• Policy routing done via firewall rules (setting a *Gateway* on a pass rule) bypasses the routing table for matching traffic and will not show in Diagnostics → Routes.
• FreeBSD flags differ from Linux/Cisco: UGS = up, gateway, static. The Expire column reveals ARP-derived host routes cluttering the view.

Steps

1. Network → Routing → Route Table — this shows the live/active table with an *Origin* column (Connected, Static, RIP, OSPF, BGP) — treat this as the FIB equivalent.
2. Network → Routing → Route Policies shows the configured policy list instead — what you told the firewall to do, including policies that reference a probe and may currently be down.
3. For OSPF/BGP-specific state, check Network → Routing → OSPF → Neighbors / BGP → Neighbors to confirm adjacencies rather than assuming a listed route is being learned live.
4. If you need a point-in-time dump for a support case, generate a Tech Support Report (Device → Diagnostics → Tech Support Report), which embeds a routing table snapshot.

Gotchas & notes

• The split this platform has is between Route Policies (config) and Route Table (installed/active) — a policy can sit there enabled and 'valid' in the list while not actually being installed, most commonly because its attached Probe/path-monitor object is failing and SonicOS has pulled it from the table automatically.
• There is no CLI show ip route / show route equivalent — the E-CLI does not expose a live routing table view. Diagnostics on this platform are GUI-driven or via the Tech Support Report download, not an interactive CLI show command.
• On boxes running a lot of policy-based routes (source/service-specific route policies, not just destination routes), the Route Table view can get large fast since each policy can expand into multiple table entries — filter by Origin/Interface rather than scrolling.

Steps

1. Insight-managed routers/Orbi Pro: check Insight Portal → Device → Overview and the configured Static Routes list under Routing — Insight generally shows you what's *configured*, not a live FIB dump; deeper visibility is limited to the built-in ping/traceroute diagnostics rather than a true routing-table view.
2. L3-capable Smart Switches: local HTTPS GUI Routing → IPv4 → Route Table shows the active/best routes actually in use.
3. M4200/M4300 local GUI: Routing → IPv4 → Route Table (installed/best routes).
4. M4200/M4300 CLI: show ip route for the actual forwarding table; show ip route static (or the configured-routes list) to see every configured static route, including ones that are not currently installed.

Gotchas & notes

• The biggest gap versus every other vendor on this site: Insight-managed routers give you no CLI and no real 'show ip route' equivalent in the cloud UI — if a route silently isn't working, you're troubleshooting with ping/traceroute from the app, not a forwarding table.
• On M4300, the same trap exists as on Cisco/FortiGate/etc.: the configured static-route list can show a route that isn't installed (interface down, a better route present) — only show ip route reflects what's actually forwarding traffic.
• Smart Switches with no L3 capability have nothing resembling a routing table beyond their single management VLAN IP — don't go looking for one.