Why the CLI Still Matters in 2026: 7 Tools Network Engineers Actually Use

## The argument has moved on Two years ago the CLI-versus-GUI debate was about control and speed. That argument is over and nobody won, because most engineers use both. The live argument in 2026 is different. It is CLI versus the assumption that something else has already answered the question for you. A dashboard that says the link is healthy. An observability platform that aggregated the problem away. An AI assistant that hands you a confident five-line command block. All three are useful. None of them are evidence. The command line is where you get evidence. When an assistant suggests `tcpdump -i eth0 -nn 'tcp port 179'` you still need to know what a BGP session looks like when it is failing to establish, otherwise you are just pasting text into a production device and hoping. The tooling got better. The requirement to understand the output got stricter, because the volume of plausible-looking suggestions went up. That is the honest 2026 case for the CLI. Not nostalgia. Verification. ## What actually changed since 2024 Four things are worth knowing before the tool list, because they change how you should use every tool on it. **Structured output is now the price of entry.** If a tool cannot emit JSON or XML, it cannot be piped into a pipeline, a runbook, a CI check or an agent. Every tool below either has a structured output mode or has a companion that does. Learn the flag, not just the command. **Polling lost to streaming.** SNMP polls are still everywhere and will be for years, but for anything modern the state comes off the box via gNMI over gRPC. There is a CLI for that now and it is good. **Labs became disposable.** You no longer need a rack or a bloated VM sprawl to test a change. Containerlab spins up a multi-vendor topology from a YAML file in under a minute. **`net-tools` is properly dead.** `netstat`, `ifconfig` and `route` are unmaintained, missing from minimal container images and behind on modern kernel features. If your runbooks still call them, they are quietly wrong. ## The five classics, still earning their place ### 1. Nmap: discovery and audit Nmap is at 7.991 as of August 2026 and it is still the fastest way to answer "what is actually on this subnet", which is almost never the same answer as "what does the IPAM say is on this subnet". The commands worth having in muscle memory: ```bash # Fast host discovery, no port scan, useful on a /16 nmap -sn 10.20.0.0/16 # Service and version detection on a single target nmap -sV -Pn 10.20.4.11 # OS fingerprint plus default scripts, slower and noisier nmap -A 10.20.4.11 # XML output, which is the one that feeds pipelines nmap -sV -oX scan.xml 10.20.4.0/24 ``` The `-oX` flag is the one most people skip and should not. Nmap has no native JSON writer, so XML is the machine-readable path, and there are plenty of converters if your pipeline wants JSON downstream. Two gotchas. First, `-Pn` matters more every year, because host discovery pings get dropped by host firewalls and you will convince yourself a live device is down. Second, run a `-A` scan against an ageing industrial or OT device and you may reboot it. Scan management ranges deliberately, not enthusiastically. Nmap also ships **Ncat**, which matters for the netcat problem below. ### 2. iperf3: throughput, and the thing everyone gets wrong iperf3 reached 3.21 in April 2026, and it has changed more than most people realise. Older blog posts (including our own 2024 version) repeat the line that iperf3 is single-threaded. That stopped being true at 3.16, which added multi-threading for parallel streams, and 3.21 added Global Segmentation Offload and Global Receive Offload support on Linux. If you tested a 25G or 100G link with iperf3 a few years ago, got a disappointing number and blamed the network, it is worth retesting on a current build before you re-cable anything. ```bash # Server side iperf3 -s # Client, 30 seconds, 8 parallel streams iperf3 -c 10.20.4.11 -t 30 -P 8 # Reverse direction, because asymmetric problems are common iperf3 -c 10.20.4.11 -R # UDP at a target rate, for jitter and loss on a voice or video path iperf3 -u -c 10.20.4.11 -b 200M # JSON out, for anything you intend to graph or gate a change on iperf3 -c 10.20.4.11 -t 30 --json > run.json ``` The `--json-stream` option gives you line-delimited JSON if you want to consume results live rather than at the end. The perennial gotcha: iperf3 measures the path between two hosts, so if one of those hosts is a tired VM with a throttled vNIC, you have measured the VM. Test host to host on known-good endpoints before you draw conclusions about the fabric. ### 3. tcpdump and tshark: the ground truth tcpdump remains the tool that ends arguments. It tells you what arrived on the wire, which is regularly not what the vendor documentation, the application team or the firewall rule review claims. ```bash # Capture, no name resolution, no truncation, write to file sudo tcpdump -i eth0 -nn -s 0 -w capture.pcap # BGP only sudo tcpdump -i eth0 -nn 'tcp port 179' # One host, both directions, excluding your own SSH session sudo tcpdump -i eth0 -nn host 10.20.4.11 and not port 22 # Ring buffer, so a long-running capture does not fill the disk sudo tcpdump -i eth0 -nn -w cap.pcap -C 100 -W 10 ``` That last one is the single most useful tcpdump habit to build. Intermittent faults need long captures, and long captures fill root partitions at three in the morning. For analysis, pair it with **tshark**, which does what tcpdump does not: ```bash # Structured output for pipelines tshark -r capture.pcap -T json # Specific fields, tabular, for grep and awk tshark -r capture.pcap -T fields -e frame.time -e ip.src -e ip.dst -e tcp.flags # Retransmissions only tshark -r capture.pcap -Y "tcp.analysis.retransmission" ``` Rule of thumb: capture with tcpdump because it is everywhere and lightweight, analyse with tshark or Wireshark because they understand the protocols. ### 4. mtr: traceroute, but useful Plain `traceroute` gives you one snapshot of a path. Almost every real problem is intermittent, so one snapshot is the wrong measurement. **mtr** combines traceroute and ping and runs continuously, which is what you actually wanted. ```bash # Report mode, 100 cycles, wide output, show ASNs and both name and IP mtr -rwzbc 100 10.20.4.11 # JSON, for a scheduled path-quality check mtr -rzc 100 --json 10.20.4.11 # TCP probes on port 443, for paths that filter ICMP and UDP mtr -T -P 443 example.com ``` Keep `traceroute` for the cases where mtr is not installed and you cannot install it, and remember `traceroute -T` for the same ICMP-filtering reason. The gotcha that costs the most time: intermediate hops showing loss are usually not the problem. Routers deprioritise ICMP responses to their own control plane while forwarding transit traffic perfectly. Loss only means something if it persists to the final hop and all hops beyond the first offender. ### 5. ss: the netstat replacement This is the correction to our 2024 article, which recapped `netstat` as a top-five tool. It is not, and has not been for some time. `ss` is part of iproute2, it reads kernel socket state directly, it is faster on busy hosts and it exposes TCP internals that netstat never did. ```bash # Listening sockets, TCP and UDP, with the owning process ss -tulpn # Established connections to a specific port ss -t state established '( dport = :443 or sport = :443 )' # Summary counts, quick health check on a busy box ss -s # TCP internals: congestion window, RTT, retransmits ss -ti ``` `ss -ti` is the underrated one. When an application team insists the network is slow, per-socket RTT and retransmit counters either support them or do not, and it takes ten seconds. ## Two tools that earned their place since 2024 ### 6. gnmic: streaming telemetry from the command line If your estate includes anything modern from Nokia, Arista, Cisco or Juniper, you can subscribe to state changes over gNMI rather than polling for them. **gnmic**, now maintained under the OpenConfig organisation, is the CLI client and collector for it. ```bash # What does this device support gnmic -a 10.20.4.11:57400 -u admin -p admin --insecure capabilities # One-shot get gnmic -a 10.20.4.11:57400 -u admin -p admin --insecure \ get --path /state/system/platform # Subscribe to a counter and watch it stream gnmic -a 10.20.4.11:57400 -u admin -p admin --insecure \ sub --path "/interfaces/interface[name=Ethernet1]/state/counters" ``` Two things make it worth the learning curve. Prompt mode turns the CLI into an interactive YANG browser, so you can find the path you need without reading a model tree in a browser tab. And the same binary runs as a collector with outputs to Prometheus, InfluxDB, Kafka and NATS, so the tool you learned for troubleshooting is the tool you deploy for monitoring. ### 7. containerlab: test it before you ship it Every tool above tells you what is happening. Containerlab lets you find out what will happen. You define a topology in YAML, and it builds the lab in containers, including Nokia SR Linux, Arista cEOS, FRR and, via vrnetlab, VM-based images such as vJunos and IOS-XR. ```yaml name: bgp-test topology: nodes: spine1: kind: nokia_srlinux image: ghcr.io/nokia/srlinux leaf1: kind: nokia_srlinux image: ghcr.io/nokia/srlinux links: - endpoints: ["spine1:e1-1", "leaf1:e1-1"] ``` ```bash containerlab deploy -t bgp-test.clab.yml containerlab inspect -t bgp-test.clab.yml containerlab destroy -t bgp-test.clab.yml ``` It runs on a laptop for small topologies and it tears down cleanly. If you have ever pushed a route-map change on a Friday because there was no way to test it, this is the tool that removes the excuse. ## A note on netcat, because the instructions everywhere are wrong Most tutorials, ours included, still say `sudo apt-get install netcat`. That command fails on Debian 12 and later and on Ubuntu 24.04 and later. The plain `netcat` package is gone. What to install instead: ```bash # Debian and Ubuntu sudo apt install netcat-openbsd # RHEL, Rocky, Alma sudo dnf install nmap-ncat ``` Note that these are not the same programme. The OpenBSD rewrite and Nmap's Ncat have different flags, which is why half the netcat one-liners on the internet do not work on the box in front of you. Ncat is the more capable of the two, with TLS and proxy support built in, and it comes along with Nmap anyway. Netcat is still worth having for quick reachability checks and file moves, but it did not make the top seven because `ss`, `curl` and `nmap` cover most of what people actually use it for. ```bash # Is the port open, no data sent nc -zv 10.20.4.11 22 # Listen on a port to prove a firewall rule works nc -l 8080 ``` ## The five-minute reference | Question | Command | |---|---| | What is on this subnet | `nmap -sn 10.20.0.0/16` | | What is this host running | `nmap -sV -Pn ` | | How fast is this path really | `iperf3 -c -t 30 -P 8 --json` | | What is actually on the wire | `sudo tcpdump -i eth0 -nn -w cap.pcap` | | Where is the loss, over time | `mtr -rwzbc 100 ` | | What is listening on this box | `ss -tulpn` | | Is TCP struggling | `ss -ti` | | What state is the device in | `gnmic ... sub --path ` | | Will this change break things | `containerlab deploy -t topo.clab.yml` | Add `jq` to that list. Every JSON flag above is half as useful without it. ## Where the CLI stops scaling Here is the part most CLI articles leave out, including ours. These tools are excellent at answering a question about one device, one path or one moment. They are poor at answering questions about an estate over time. Nobody has ever debugged a configuration drift problem across four hundred devices with tcpdump, and nobody should try. The questions that break the CLI model are: - Which devices changed in the last 24 hours, and what changed in them - Which running configs no longer match the intended standard - What did this switch look like before last Tuesday's outage - Which devices still have a deprecated NTP server, an unencrypted SNMP community, or a stale ACL entry - Can you evidence any of that to an auditor without a week of screenshots You can script your way toward all of that with `expect`, cron and a Git repo, and plenty of engineers have. It works until the credential rotation, the vendor that reformats its output, the box that hangs mid-collection, or the person who wrote it leaves. This is the gap rConfig v8 fills. Scheduled multi-vendor configuration collection, full version history with diffs between any two points in time, search across every config in the estate, compliance policies that flag the config that does not match standard, and an API so the whole thing plugs into the pipelines you are already running. It does not replace the seven tools above and it is not trying to. It replaces the pile of half-maintained collection scripts sitting between them and your evidence. The mindset carries over. If you already think in terms of structured output, version control and automation, you will find rConfig behaves the way you expect. ## Closing Nmap, iperf3, tcpdump with tshark, mtr, ss, gnmic and containerlab. That is the working set for 2026, and it will still be broadly right in 2027. None of them are hard. The hard part was never the syntax, it was knowing which question to ask and being able to read the answer. Tooling has become very good at producing plausible commands, and correspondingly, the engineer who can tell a real result from a confident wrong one has become more valuable, not less. Learn the structured output flags. Capture to a ring buffer. Test in a lab you can destroy. And move configuration management off the ad-hoc scripts before it becomes someone else's archaeology project. --- *rConfig is a multi-vendor network configuration management platform built for engineers who live in the CLI. See the [rConfig v8 documentation](https://docs.rconfig.com) or [book a demo](https://www.rconfig.com/demo-request).*