NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: WinBox/WebFig → Tools → Ping, put the target in *Ping To*, click Start.
2. CLI: /ping 8.8.8.8 count=4
3. Pick a source: /ping 8.8.8.8 src-address=192.168.88.1 or /ping 8.8.8.8 interface=ether1

Gotchas & notes

• Without count=, /ping runs forever — stop it with Ctrl+C (or the Stop button in WinBox).
• RouterOS picks the source address from the routing table. If you are testing whether a *remote* site can reach your LAN subnet, you must set src-address= to a LAN IP or you will silently test the WAN IP instead.
• /ping to a DNS name needs a working resolver on the router (/ip dns), which is configured separately from the DHCP-client-provided DNS used by LAN hosts.

Steps

1. There is no ping tool in the FortiOS GUI. Open the CLI Console — the >_ icon in the top-right of the web UI — or SSH in.
2. execute ping 8.8.8.8
3. To control the source or count, set options *before* pinging: execute ping-options source 192.168.1.99 then execute ping-options repeat-count 5 then execute ping 8.8.8.8

Gotchas & notes

• This is the single most common cross-vendor surprise: FortiGate has no GUI ping. People coming from pfSense or MikroTik hunt through Network and Monitor menus and conclude the feature is missing. It is in the CLI Console only.
• execute ping-options values persist for the rest of your CLI session. If you set source once and forget, every later ping in that session is sourced from that address. Reset with execute ping-options reset.
• By default the ping is sourced from the egress interface chosen by the routing table, so a ping that works from the FortiGate does not prove a policy allows LAN clients through — the firewall's own outbound traffic is not evaluated against firewall policies.
• With VDOMs enabled you must be in the right VDOM first (config vdom → edit <name>), otherwise you are pinging from the management VDOM's routing table.
• Ping *to* the FortiGate is controlled by the interface's allowaccess list, not by a firewall policy — if the FortiGate will not answer pings, check config system interface → set allowaccess ping.

Steps

1. GUI: UniFi Network → Devices, click the device you want to ping *from*, open the Tools tab (older versions: the wrench icon), choose Ping, enter the target, Run.
2. CLI (gateways only): SSH to the UDM/UDM-Pro/UXG and run ping -c 4 8.8.8.8.

Gotchas & notes

• The ping runs from the selected UniFi device, not from the controller. Pinging from an AP and pinging from the gateway test completely different paths — pick the device deliberately.
• Device SSH is off by default and must be enabled site-wide under Settings → System → Advanced → Device SSH Authentication, where you also set the SSH username/password.
• The GUI tool gives you no source-address control at all. If you need that, SSH to the gateway and use ping -I <interface>.
• Menu location for device Tools has moved repeatedly across UniFi Network 7.x → 9.x. If Tools is not on the device panel, look for the wrench/insights icon or use SSH.

Steps

1. ping 8.8.8.8
2. For source control, use extended ping: type ping with no arguments in enable mode and answer the prompts (Target, Repeat count, Datagram size, Source address or interface).
3. One-liner alternative: ping 8.8.8.8 source Vlan10 repeat 100
4. In a VRF: ping vrf MGMT 8.8.8.8

Gotchas & notes

• Default is 5 packets with a 2-second timeout, so a fully failing ping takes 10 seconds to come back with ......
• Extended ping (the interactive prompt version) only works from enable mode, not user mode. From user mode you get the basic form with no source option.
• Read the result characters, they are not all failures: ! = reply, . = timeout, U = destination unreachable received, M = fragmentation needed (MTU problem), Q = source quench. A wall of U means a router is actively telling you no — very different from ..
• If the device has a VRF-aware management interface, plain ping uses the global table and will fail even though the box is reachable. Always check whether you need vrf.

Steps

1. No ping tool in the PAN-OS GUI. SSH to the firewall (operational mode).
2. ping host 8.8.8.8
3. Source from a dataplane interface: ping source 10.1.1.1 host 8.8.8.8
4. Count: ping count 4 host 8.8.8.8

Gotchas & notes

• By default ping is sourced from the management interface, which usually has a totally different route and often no internet path. A failed ping host 8.8.8.8 on a PAN-OS box frequently means nothing about your data plane — re-run with source <dataplane-ip>.
• Without count, ping runs continuously; Ctrl+C stops it.
• Note the syntax order: options come *before* host, and host is a required keyword. ping 8.8.8.8 alone is a syntax error, which trips up everyone arriving from any other vendor.
• To test through a specific virtual router use ping source <ip-in-that-vr> host <target>; there is no vrf-style keyword.

Steps

1. GUI: Diagnostics → Ping, set *Hostname*, *IP Protocol*, Source Address, and Count, then Ping.
2. CLI: console/SSH → option 8) Shell → ping -c 4 8.8.8.8

Gotchas & notes

• The GUI has a proper *Source Address* dropdown listing every interface and VIP — this is the easiest source-selection of any vendor here, and worth using instead of the shell.
• Traffic originating from pfSense itself is not filtered by the interface rules you wrote for clients, so a successful ping from the firewall does not validate your LAN ruleset.
• Count is capped in the GUI (10 by default) and the page blocks while it runs; for long-running tests use the shell.
• Selecting a *source* on an interface whose gateway is not the default will still follow the routing table — use Diagnostics → Routes to confirm which gateway the packet takes when policy routing is in play.

Steps

1. GUI: Device > Diagnostics > Diagnostic Tools, then pick Ping from the "Perform" dropdown.
2. Enter the destination IP/hostname. The ping tool also exposes a source-interface dropdown (e.g. X0, X1, a specific VLAN) so you can force which interface the probe leaves from instead of letting the route table decide.
3. Click Ping/Go and read RTT and loss results in the results pane.
4. CLI: SSH or connect via console, then run ping <ip-address> from the E-CLI prompt. Basic diagnostics like ping are one of the few things the CLI covers even though most configuration lives in the GUI.

Changed across versions

• 7.0SonicOS 7.0's GUI overhaul moved diagnostic tools (ping included) from the old System > Diagnostics path used in 6.5 and earlier into Device > Diagnostics / the newer Investigate tab; exact menu wording shifted with it.

Gotchas & notes

• The GUI's source-interface picker is the main reason to prefer it over CLI: a default routed ping (or CLI ping with no source override) leaves from whatever interface the routing table picks — usually a WAN — which can make a 'yes it pings' result meaningless if what you actually needed to test was LAN-side reachability.
• A ping sourced from the SonicWall itself is not evaluated against normal LAN->WAN Access Rules the way client traffic is — it's matched against rules/trust involving the firewall's own interface as source or destination. A successful self-ping does not prove an ordinary client behind the firewall can reach the same host.
• The GUI diagnostic tool runs a fixed short burst, not a continuous ping — for a long-running ping you want CLI/console, not the diagnostics page.

Steps

1. First figure out which of the three NETGEAR 'platforms' you're actually touching — this determines whether a CLI even exists.
2. Cloud/GUI (works for Insight-managed routers, Orbi Pro APs, and Insight-managed switches): in the Insight portal or app, select the device, open the Utilities / Diagnostics tab (wording varies by device type — routers show it under the device detail page, switches under Topology > device), choose Ping, enter the target IP/host, and run. The device runs the ping locally and reports the result back through the cloud tunnel.
3. Local GUI (switches only): log into the switch's own local HTTPS management page and go to Maintenance > Diagnostics > Ping, enter the target, run.
4. CLI (M4200/M4300 fully-managed line only): console or SSH in, ping <ip-address>, optionally ping <ip-address> repeat <n>.
5. CLI (Smart Switch Lite CLI): SSH in, ping <ip-address> — a basic reachability check is supported, don't expect extra flags.
6. Insight-managed routers and Orbi Pro APs have no SSH/console service at all — the Insight cloud ping tool in step 2 is the *only* way to originate a ping from the box itself.

Gotchas & notes

• Don't go hunting for an SSH port on an Insight-managed router expecting a ping command — there is none. This is the single biggest cross-vendor surprise for anyone coming from MikroTik or pfSense: 'the box' here often just means the cloud portal.
• Insight's cloud ping round-trips through NETGEAR's cloud broker, so a timeout can mean the device's cloud tunnel is flaky rather than the destination being unreachable — don't treat a failed Insight ping as proof of a routing problem without also checking device online status.
• There's no equivalent of FortiGate's ping-options source — ping source address is whatever the device's own routing table picks, and it isn't configurable on any of the three tiers.