NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: Interfaces list shows live Tx/Rx columns; double-click an interface → Traffic tab for a live graph.
2. CLI: /interface monitor-traffic ether1 (add once for a single sample).
3. Historical graphs: Tools → Graphing → configure interface graphs, then browse to http://<router>/graphs/.
4. Per-torch (top talkers): Tools → Torch or /tool torch interface=ether1

Gotchas & notes

• Tools → Torch is the standout feature: it breaks live traffic down by src/dst/protocol/port on the spot, answering 'what is eating my bandwidth' without a capture. No other vendor here has an equivalent one-click tool.
• /interface monitor-traffic shows an instantaneous rate, so it catches bursts that averaged counters miss.
• Graphing must be enabled *before* the incident to have history; it stores RRD data on the router and is off by default.

Steps

1. GUI: Network → Interfaces — hover/expand an interface for its bandwidth widget; Dashboard → FortiView → Interface Bandwidth for a live chart.
2. Top talkers: Dashboard → FortiView → Sources / Destinations / Applications.
3. CLI counters: get system interface physical
4. CLI live-ish: diagnose netlink interface list <port> for per-interface stats and errors.

Gotchas & notes

• FortiView is the useful half of the FortiGate GUI and depends on logging being enabled — with logging off or memory-only, FortiView is empty or covers only a few minutes.
• get system interface physical includes link status, speed/duplex, and error counters, making it the fastest check for a duplex mismatch or a flapping SFP.
• Interface graphs in the GUI are sampled; a short saturating burst may not be visible. Correlate with diagnose sys session stat and error counters.

Steps

1. Devices → <device> → Ports for per-port live rates and link speed.
2. Insights → Traffic (or *Statistics*) for site-wide and per-client trends.
3. Clients → <client> for that client's up/down history.

Gotchas & notes

• UniFi's traffic graphs are the best-looking of the six and the easiest to hand to a non-engineer, but they are polled at coarse intervals — treat them as trends, not measurements.
• Deep per-application breakdown requires DPI / Traffic Identification to be enabled in Settings, which costs gateway CPU and is off by default on some models.
• Historical retention depends on the controller's storage and version; a reprovisioned or migrated controller loses history.

Steps

1. show interfaces GigabitEthernet1/0/1 | include rate|error|drop
2. Make the average responsive first: interface Gi1/0/1 → load-interval 30
3. Quick summary of all ports: show interfaces summary or show interfaces counters
4. Top talkers need NetFlow/NBAR: show ip cache flow / show ip nbar protocol-discovery

Gotchas & notes

• The 5 minute input rate line is exactly that — a 5-minute average. A link that saturates for 20 seconds will show a modest average. Set load-interval 30 on ports you monitor so the number reacts.
• Check output drops / total output drops alongside the rate: drops with a low average rate is the signature of microbursts hitting a small buffer.
• Counters are cumulative since last clear. Run clear counters Gi1/0/1 to get a clean baseline, and remember it resets everyone else's view too.
• show interfaces also exposes CRC/input errors — CRCs point at cabling/SFPs, input errors with no CRCs often point at duplex mismatch.

Steps

1. GUI: Network → Interfaces, click the interface → *More Runtime Stats* for counters; ACC (Application Command Center) for what the traffic actually is.
2. CLI: show interface ethernet1/1 for state and counters.
3. Hardware counters and drops: show counter interface ethernet1/1
4. Global drops: show counter global filter severity drop

Gotchas & notes

• The ACC is where PAN-OS shines for 'what is using my bandwidth' — it breaks down by application rather than port, so it identifies traffic that hides on 443.
• show counter global filter severity drop is the single most valuable troubleshooting command on the platform: it names the exact reason packets were discarded (policy deny, TCP out-of-window, zone mismatch, etc.).
• There is no simple live bits/sec CLI meter; for a real-time rate use the GUI interface widget or poll SNMP.

Steps

1. GUI: Status → Interfaces for counters and link state; Status → Traffic Graph for a live per-interface graph.
2. Status → Monitoring for historical RRD graphs (traffic, quality, states).
3. Top talkers: Diagnostics → pfTop, or install the *ntopng* / *Darkstat* package.
4. CLI: netstat -ihw 1 or systat -ifstat

Gotchas & notes

• Status → Traffic Graph has a *Display* mode that lists the top hosts alongside the graph — a lightweight equivalent of MikroTik's Torch, and it needs no packages.
• RRD monitoring data is retained by default and survives reboots, so pfSense is the one box here that usually *does* have the history you want after the fact.
• Diagnostics → pfTop with view queue is the way to confirm traffic shaping is doing what you think.
• Graphs read from the interface the GUI is loaded over too, so your own session shows up in the numbers on low-traffic links.

Steps

1. GUI: Monitor > Appliance > Interface (naming can vary slightly by firmware build; on some it sits directly under Network > Interfaces) shows a per-interface real-time Rx/Tx graph plus current packet/error/drop counters.
2. There's also a dedicated Network Monitor tool under Device > Diagnostics > Diagnostic Tools that graphs a chosen interface's bandwidth live in a larger view, handy for watching one link full-screen while generating load elsewhere.
3. CLI: show interface <name> returns current counters (bytes/packets in/out, errors, drops) as a point-in-time snapshot — not a live rate — so you have to poll it repeatedly to see a trend.

Gotchas & notes

• The GUI graphs are the only place you actually see a moving real-time rate; CLI only gives cumulative counters at the instant you run the command, so scripting show interface polling is a poor substitute for watching the graph if you're hunting a live saturation event.
• Some of the GUI interface graphs use a smoothed/averaged sampling interval rather than an instantaneous rate — a short, hard microburst that fully fills the link for a second or two can be completely invisible on the graph. If you suspect microbursts, corroborate with Packet Monitor or an external tap rather than trusting the graph alone.

Steps

1. Cloud/GUI (all device types): Insight portal/app > device > Ports (switches) or the device dashboard traffic widget (routers/Orbi Pro APs) shows a per-port/interface throughput graph, cloud-polled and rendered as a smoothed graph rather than an instantaneous reading.
2. Local GUI (switches): Monitoring > Port Statistics (or the dashboard) on the switch's local HTTPS page shows raw in/out byte and packet counters, manually or auto-refreshed — closer to real-time since there's no cloud-polling delay.
3. CLI (M4200/M4300): show interfaces <if> or show interfaces counters returns cumulative packet/byte/error counters — there's no built-in live bits/sec meter, you run it twice and compute the delta yourself.
4. CLI (Smart Switch Lite CLI): a reduced show interface/show port-style counter dump is available with the same caveat — raw cumulative counters only.

Gotchas & notes

• This is a weak spot for catching microbursts: Insight's cloud graphs are polled on the order of minutes, so a link saturating for a few seconds and recovering can be completely invisible in the Insight UI. You have to be watching local GUI or CLI counters in a tight loop at the moment it happens.
• No tier here gives you a native 'instantaneous bits/sec' readout — every CLI path hands you raw cumulative counters and expects manual rate math, which is easy to forget if you're used to a dashboard doing it for you.
• Local switch GUI refresh/polling intervals vary by model and firmware and aren't consistently documented — treat any 'live' number in the local GUI as approximate unless you've timed it yourself.