NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: IP → Routes → + → *Dst. Address* 10.20.0.0/16, *Gateway* 192.168.88.254.
2. CLI: /ip route add dst-address=10.20.0.0/16 gateway=192.168.88.254 comment="to branch"
3. Default route: /ip route add dst-address=0.0.0.0/0 gateway=203.0.113.1
4. Verify: /ip route print and /ip route check 10.20.0.5

Changed across versions

• 6.xMultiple routing tables are done with routing marks (routing-mark=) tied to firewall mangle rules — a mark-based, indirect approach.
• 7.xRouting moved to a new engine. Use routing-table= to place a route directly into a named table — the old mark-based indirection is gone, and RouterOS 6 configs referencing routing marks do not carry over.

Gotchas & notes

• Default distance=1. Add a floating backup with a higher distance: distance=2 — the higher-distance route only installs when the first gateway is unreachable.
• A gateway that is not directly reachable makes the route inactive rather than erroring. In /ip route print, look for the A (active) flag — a route without it is being ignored.
• Add check-gateway=ping for the route to be withdrawn when the next hop stops responding; without it RouterOS keeps a dead route installed as long as the interface is up.

Steps

1. GUI: Network → Static Routes → Create New → *Destination* 10.20.0.0/16, *Gateway Address*, *Interface*, *Administrative Distance*.
2. CLI: config router static → edit 0 → set dst 10.20.0.0 255.255.0.0 → set gateway 192.168.1.254 → set device "port2" → next → end
3. Verify: get router info routing-table static and get router info routing-table all

Gotchas & notes

• Default administrative distance for a static route is 10, not 1 as on Cisco, IOS-XE, and MikroTik. It still beats OSPF (110) and BGP, so normal designs behave the same — but if you are recreating a Cisco config that relied on specific distance values for failover, the numbers will not line up.
• set device (the outgoing interface) is effectively mandatory. A route with a gateway but no device may not install.
• Priority vs distance: distance decides which route enters the routing table; priority decides between equal-distance routes for ECMP. Setting distance where you meant priority quietly disables a path.
• get router info routing-table all shows the FIB; the GUI *Network → Static Routes* list shows configuration, including routes that are not installed. Always confirm in the routing table.

Steps

1. Settings → Routing (older: *Settings → Routing & Firewall → Static Routes*) → Create New Route.
2. Set *Name*, *Destination Network*, *Distance*, and either a *Next Hop* IP or an interface/VPN target.
3. Save — the gateway reprovisions.

Changed across versions

• 8.x and earlierSettings → Routing & Firewall → Static Routes.
• ~9.2Renamed to a standalone Settings → Routing page.
• 10.xMoved under the unified policy UI: Settings → Policy Table → Create New Policy → Route, the same screen used for firewall rules.

Gotchas & notes

• Static routes apply to the gateway only; UniFi switches with L3 features are configured separately per-switch and do not appear here.
• Saving triggers a gateway provision, which briefly interrupts forwarding on some models — avoid batching many route changes during business hours.
• There is no route-verification view in the UI. To confirm the route installed, SSH to the gateway and run ip route show.

Steps

1. ip route 10.20.0.0 255.255.0.0 192.168.1.254
2. Default route: ip route 0.0.0.0 0.0.0.0 203.0.113.1
3. In a VRF: ip route vrf MGMT 10.20.0.0 255.255.0.0 192.168.1.254
4. Save it: copy running-config startup-config
5. Verify: show ip route 10.20.0.5 and show ip cef 10.20.0.5

Gotchas & notes

• A static route is not saved until you copy running-config startup-config. It works immediately and vanishes on reload — the defining IOS gotcha.
• Default administrative distance is 1. Add a trailing number for a floating static: ip route 0.0.0.0 0.0.0.0 203.0.113.1 200.
• A static route pointing out a multi-access interface without a next-hop IP (e.g. ip route 10.0.0.0 255.0.0.0 Gi0/1) makes the router ARP for every destination in the prefix. Always give a next-hop IP on Ethernet.
• Subnet mask, not wildcard, in ip route — the opposite of ACL syntax on the same box.
• IOS installs a static route even when the next hop is unreachable, as long as the outgoing interface is up. Use ip route ... track <object> or IP SLA for real failover.

Steps

1. Network → Virtual Routers → <router> → Static Routes → Add. Set *Name*, *Destination*, *Interface*, *Next Hop* (IP Address), *Metric*, *Admin Distance*.
2. Commit.
3. CLI: configure → set network virtual-router default routing-table ip static-route to-branch destination 10.20.0.0/16 nexthop ip-address 192.168.1.254 interface ethernet1/2 → commit
4. Verify: show routing route and test routing fib-lookup virtual-router default ip 10.20.0.5

Gotchas & notes

• Routes live inside a virtual router. With multiple VRs, adding the route to the wrong one is a silent no-op — check which VR owns the relevant interfaces first.
• Requires a Commit like every PAN-OS change; the route does nothing until then.
• Enable Path Monitoring on the static route to have it withdrawn when the next hop dies. Without it the route stays installed while the interface is up.
• test routing fib-lookup is the definitive check — it tells you the actual egress interface and next hop the dataplane will use.

Steps

1. First create the gateway if it does not exist: System → Routing → Gateways → Add (interface + gateway IP).
2. Then System → Routing → Static Routes → Add → *Destination network*, *Gateway*, *Description*.
3. Save → Apply Changes.
4. Verify: Diagnostics → Routes.

Gotchas & notes

• A static route needs a Gateway object first. You cannot type a next-hop IP directly into the route — this two-step requirement is the usual point of confusion for people arriving from MikroTik or Cisco.
• The gateway must be on a subnet already configured on an interface, or pfSense will refuse to save it.
• Marking a gateway as *Default* in System → Routing → Gateways is how you set the default route — do not create a 0.0.0.0/0 static route for that.
• Gateway monitoring is on by default and will mark a gateway down (removing dependent routes) if the monitor IP stops answering ICMP. If a route disappears mysteriously, check Status → Gateways and the monitor IP.

Steps

1. SonicOS doesn't have a plain 'static route' object — it uses generalized Route Policies, which are policy-based (source + destination + service), not just destination-based.
2. First create an Address Object for the destination network: Object → Address Objects → Add (or Network → Address Objects depending on firmware build) → Name it, Zone Any, Type Network, Network 10.20.0.0, Netmask 255.255.0.0. You generally cannot type a raw prefix directly into the route policy — it has to reference an Address Object (or Any).
3. Network → Routing → Route Policies → Add → *Source*: Any, *Destination*: the address object you just made, *Service*: Any, *Gateway*: 192.168.1.254, *Interface*: X1, *Metric*: 1 (default), leave *Enable* checked. Optionally attach a *Probe* (path-monitoring object) so the policy auto-withdraws if the gateway stops responding.
4. If SonicOS 7 shows a pending-changes banner at the top of the page, click Accept to apply.
5. Verify: Network → Routing → Route Table — confirm the route shows Origin Static/Policy and is actually installed, not just listed under Route Policies.

Gotchas & notes

• There is no CLI equivalent of ip route / set static-route. The SonicOS E-CLI has no command to create a Route Policy — this is entirely a GUI-only feature, one of the clearest cases where the CLI is bootstrap/diagnostics-only, not a config mirror.
• Because routes are 'Route Policies', the Destination field wants an Address Object, not a typed prefix. Admins coming from Cisco/MikroTik/pfSense who expect to type 10.20.0.0/16 inline will hit a dead end until they create the object first.
• SonicOS has no administrative-distance model split by protocol the way Cisco/RouterOS/FortiGate do. The only tie-breaker is the numeric Metric field (lower wins) plus longest-prefix-match; there's no clean way to make a static route a low-priority 'floating' backup to OSPF purely via distance the way ip route ... 200 does on IOS.
• No virtual router / VRF concept exists in SonicOS — one flat global routing table per appliance (this is different from FortiGate VDOMs-with-VRF or PAN-OS virtual routers). VLAN interfaces just participate in the single table like any other interface.
• Changes generally apply immediately (no PAN-OS-style commit step), but SonicOS 7's UI does show an 'accrued changes / Accept' banner for some settings — worth glancing at after adding a route policy.

Steps

1. Insight-managed routers (BR series) & Orbi Pro: Insight Portal/App → select the router → Configuration → Routing (or LAN → Routing depending on model) → Static Routes → Add → set Destination Network, Subnet Mask, Gateway IP (or egress WAN/LAN interface), and Metric, then Save — Insight pushes the change to the device on its next check-in, there is no separate 'commit' step beyond Save/Apply.
2. Smart Switches: most Smart Switches are L2-only and have no static-route concept at all; the handful of L3-capable Smart Switch SKUs expose Routing → IPv4 → Static Routes in the per-device local HTTPS GUI. The Lite CLI on these switches is monitoring/VLAN-oriented and does not expose route configuration — use the local GUI, not SSH, for this.
3. M4200/M4300 (fully-managed): local HTTPS GUI Routing → IPv4 → Route Table → Static Routes → Add.
4. M4200/M4300 CLI: enable → configure → ip routing (if not already enabled) → ip route 10.20.0.0 255.255.0.0 192.168.1.254 1 (network, mask, next-hop, optional preference) → exit.

Gotchas & notes

• There is no single 'default distance' for this vendor — Insight-managed routers don't expose a distance/preference concept in the app at all (it's abstracted away), while the M4300's FASTPATH-derived CLI calls it 'preference' and defaults to 1 for static routes.
• On M4300, ip routing must be enabled globally and the VLAN interface must already have an IP address assigned — add the route before that and it will accept the command but never install, which looks identical to a typo until you check show ip route.
• Static routing is simply absent on the majority of the Smart Switch line — don't assume 'it's a managed switch' means it can route; check the specific model's L2/L3 designation before promising this feature.
• Insight-managed router changes are queued, not instant: if the device is offline or mid check-in, the route won't appear until it re-syncs — there's no local fallback console to verify or force-apply it.