NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: Tools → Traceroute, enter the address, Start.
2. CLI: /tool traceroute 8.8.8.8
3. With a source: /tool traceroute 8.8.8.8 src-address=192.168.88.1

Gotchas & notes

• RouterOS traceroute runs continuously and keeps updating loss/latency per hop like a live MTR — it is not a one-shot list. Ctrl+C when you have seen enough.
• Defaults to UDP probes; add protocol=icmp when the far end or a middle hop drops UDP.
• Because it re-probes forever it is genuinely useful as a poor-man's SmokePing during an incident — leave it running while you change something.

Steps

1. CLI Console (>_ icon) or SSH.
2. execute traceroute 8.8.8.8
3. Set options first if needed: execute traceroute-options source 192.168.1.99, then run the traceroute.

Gotchas & notes

• Same story as ping: no GUI traceroute anywhere in FortiOS.
• execute traceroute-options persists for the session exactly like ping-options does — reset it with execute traceroute-options reset.
• FortiOS traceroute uses UDP probes by default, so hops behind UDP-blocking devices show as * * * even when the path is fine. Confirm with execute ping before believing a black hole.

Steps

1. GUI: Devices → <device> → Tools → Trace (labelled *Traceroute* in some versions).
2. CLI (gateway): SSH to the UDM/UXG → traceroute 8.8.8.8 or mtr 8.8.8.8 if present.

Gotchas & notes

• As with ping, the trace originates from the selected device — an AP's path to the internet goes through your gateway, so tracing from an AP adds a hop you may misread as a problem.
• No source or protocol selection in the GUI.

Steps

1. traceroute 8.8.8.8
2. Extended form: type traceroute alone in enable mode and answer the prompts to set source, protocol, TTL range, and probe count.
3. One-liner: traceroute 8.8.8.8 source Vlan10
4. In a VRF: traceroute vrf MGMT 8.8.8.8

Gotchas & notes

• IOS uses UDP probes to high ports by default. Many firewalls drop those — use extended traceroute and choose ICMP when a path dies at exactly the firewall hop.
• Cisco's default is 3 probes per hop and a 3-second timeout, so a long dead path is slow. Reduce *Maximum Time to Live* in the extended form to stop early.
• traceroute from user mode has no source option; you need enable mode for the extended version.

Steps

1. SSH, operational mode.
2. traceroute host 8.8.8.8
3. From a dataplane interface: traceroute source 10.1.1.1 host 8.8.8.8

Gotchas & notes

• Sourced from the management interface unless you pass source, same trap as ping.
• host is a required keyword here too — traceroute 8.8.8.8 is invalid syntax.
• PAN-OS traceroute is the underlying Linux tool, so traceroute options like no-resolve are available via tab-completion if you need faster output.

Steps

1. GUI: Diagnostics → Traceroute — set *Hostname*, *Source Address*, *Maximum number of hops*, and tick Use ICMP if UDP is being dropped.
2. CLI: shell → traceroute -n 8.8.8.8 or traceroute -I 8.8.8.8 for ICMP.

Gotchas & notes

• The GUI has an explicit Use ICMP checkbox — flip it before assuming a path is broken, because the FreeBSD default is UDP.
• The page blocks until the trace finishes and the default hop count is 18; lower it when you expect failure so you are not waiting on timeouts.

Steps

1. GUI: Device > Diagnostics > Diagnostic Tools, "Perform" dropdown → Traceroute.
2. Enter the destination and (optionally) max hop count, click Go, and read the per-hop RTT list.
3. CLI: traceroute <ip-address> from the E-CLI prompt over SSH or console.

Changed across versions

• 7.0Moved from System > Diagnostics (6.5-era menu naming) into Device > Diagnostics with the 7.0 GUI redesign.

Gotchas & notes

• SonicOS's traceroute is ICMP-based rather than the UDP-probe default used by Linux/Cisco traceroute, and there's no toggle to switch probe protocol. A hop that blocks ICMP but happily passes the real application traffic will show as a timeout even though the actual path is fine.
• There's no per-hop source-interface control the way the ping tool has — traceroute always follows the routing table's chosen egress.
• A string of * * * past a certain hop is common on multi-vendor paths where an intermediate firewall (of any brand) rate-limits or drops ICMP TTL-exceeded/echo traffic by default — don't assume it means the real path is broken.

Steps

1. Cloud/GUI (routers, Orbi Pro APs, Insight-managed switches): Insight portal/app > device > Utilities/Diagnostics tab > Traceroute, enter the destination, run. Same tool and location as the ping test.
2. Local GUI (switches): Maintenance > Diagnostics > Traceroute on the switch's local HTTPS page, where present.
3. CLI (M4200/M4300 only): traceroute <ip-address>.
4. CLI (Smart Switch Lite CLI): traceroute is not in the Lite CLI command set — ping is the only reachability command exposed.
5. Routers/Orbi Pro APs: the Insight cloud tool from step 1 is the only path — no CLI exists on these at all.

Gotchas & notes

• Don't expect traceroute on a Smart Switch SSH session just because it exists on the M4300 — the Lite CLI is genuinely a subset, and this is one of the commands that got cut.
• No probe-protocol control (ICMP vs UDP) is exposed anywhere on this platform — you get whatever NETGEAR hardcoded, so you can't switch protocols to get past a UDP-blocking firewall the way you might elsewhere.
• Cloud traceroute through Insight is noticeably slower than a local CLI traceroute — each hop's probe result has to relay back through the cloud tunnel, so budget extra wait time before assuming it hung.