The command-line tools every network professional uses. Actually running these turns abstract concepts into concrete intuition — and they're genuinely useful diagnostic skills.
ping = is this host reachable? tracert / traceroute = what path do packets take? nslookup / dig = what's the DNS resolution for this name? ipconfig / ifconfig / ip addr = what's my device's network configuration? netstat / ss = what connections are open on my machine? nmap = what ports are open on another machine? Wireshark = capture and inspect packets. Each tool sits at a specific OSI layer and answers a specific diagnostic question.
18.1 Why Do the Commands Yourself
Every concept in this guide — IP addresses, DNS, routing, subnets, ports, protocols — can be seen live on any computer in about two minutes. Reading about ping is fine; running ping and seeing the round-trip times between your machine and a real website is better. The concepts lock in.
Also: the commands are standard across career paths. A network engineer uses them. A system administrator uses them. A security analyst uses them. A software developer debugging a connectivity issue uses them. Time spent learning them is never wasted.
HOW TO ACTUALLY TRY THESE: On Windows, open PowerShell or Command Prompt. On macOS, open Terminal. On Linux, Terminal. No special privileges needed for most of these commands (except nmap, which requires installation and responsible use). All examples in this chapter are safe to run against your own machine and public websites.
18.2 ping — Is It Alive?
ping sends a small ICMP Echo Request packet to a target and waits for an Echo Reply. It tests basic reachability at Layer 3 (IP).
ping google.com # On Windows this sends 4 pings by default; on macOS/Linux it runs forever until Ctrl+C. # On Linux/macOS use: ping -c 4 google.com
Typical output:
Reply from 142.250.76.78: bytes=32 time=14ms TTL=116
Reply from 142.250.76.78: bytes=32 time=13ms TTL=116
Reply from 142.250.76.78: bytes=32 time=15ms TTL=116
Reply from 142.250.76.78: bytes=32 time=13ms TTL=116
Ping statistics for 142.250.76.78:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 15ms, Average = 13ms
What ping tells you:
Reachability — does the target respond at all?
Latency — how long does a round trip take (the time=14ms part)
Packet loss — are some pings dropped?
Consistency — do the times vary wildly (jitter)?
DNS working — the fact that google.com resolved to an IP at all means DNS is working (covered below)
TRAP: "ping failed, so the target is down" — not always. Many servers deliberately drop ICMP to reduce scanning noise (common on firewalls). Failed ping doesn't prove a target is offline; it just means ICMP didn't get through. If a web server doesn't respond to ping but loads in your browser, that's not a bug — it's intentional configuration.
Ping as a security tool
Attackers use ping sweeps to map which IPs on a network are live. This is why corporate firewalls often block inbound ICMP from the internet. Defenders can also use ping to verify a suspected compromised host's connectivity, check a DDoS isn't starving the network, or script availability monitoring.
18.3 tracert / traceroute — What Path Does It Take?
This one is genuinely delightful to watch. tracert (Windows) / traceroute (macOS, Linux) reveals the sequence of routers your packets traverse on the way to a destination.
tracert google.com# Windows traceroute google.com# macOS/Linux
How it works (this is clever): it sends packets with increasing TTL (Time To Live) values. TTL=1 makes the first router drop the packet and send back an error. TTL=2 lets it pass the first router but the second drops it. By walking TTL up from 1, each successive router reveals itself in the errors. Sequencing these reveals the whole path.
Typical output (abbreviated):
Tracing route to google.com [142.250.76.78]
1 1 ms 1 ms 1 ms 192.168.1.1 (home router)
2 12 ms 11 ms 12 ms 10.0.12.1 (ISP edge)
3 13 ms 13 ms 13 ms syd-bb1-ae3.in.telstra.net (Telstra backbone)
4 20 ms 19 ms 20 ms i-92.gw1.syd9.telstra.net
5 21 ms 20 ms 21 ms 182.156.5.18
6 22 ms 22 ms 21 ms 142.250.76.78 (Google)
What this reveals:
The first hop is almost always your home router (192.168.x.x)
Then one or more ISP routers (in Australia, typically Telstra/Optus backbone names)
Eventually hand-off to the destination's network
Each hop's RTT tells you roughly where latency appears — a big jump between two hops is usually a long-distance link
REAL USE: If a website is slow, tracert tells you where it's slow. Is your home router OK? Is your ISP fine? Is the trouble happening further out? The jump between "ISP edge" and "backbone" is often where throttling or congestion shows up. This is network engineering's single most useful diagnostic.
18.4 nslookup / dig — DNS Resolution
These tools let you manually do DNS queries — the same ones your browser does automatically. Useful for diagnosing DNS issues, checking if DNS records are propagating, or investigating suspicious domains.
nslookup google.com# Works on Windows, macOS, Linux
# More powerful (Linux/macOS, or install on Windows): dig google.com
# Ask a specific DNS server: nslookup google.com 1.1.1.1
"Non-authoritative" means the answer came from cache, not directly from the authoritative server
Returns both IPv4 (A record) and IPv6 (AAAA record)
Looking at other DNS record types
# Mail server for a domain: nslookup -type=MX example.com
# Name servers (who is authoritative): nslookup -type=NS example.com
# Any SPF/DKIM/DMARC records (TXT): nslookup -type=TXT example.com
Why defenders care: checking TXT records for SPF/DKIM/DMARC is a way to verify whether a domain is protected against spoofing. Suspicious domains in phishing emails can be investigated this way — how old is the domain, where does it resolve, who owns it?
18.5 ipconfig / ifconfig / ip addr — Your Own Configuration
Shows your device's network configuration: IP address, subnet mask, default gateway, DNS servers.
ipconfig# Windows — short summary ipconfig /all# Windows — verbose ifconfig# macOS / older Linux ip addr# Modern Linux
What you'll typically see on a home Wi-Fi connection:
The subnet mask (here /24) tells you how big your network is
The default gateway is your router — every packet to outside this subnet goes here
The DNS servers are what your machine asks for name resolution
The MAC / Physical Address is your network card's unique identifier (burned in; may be randomised by modern OSes)
Useful extras
# Release/renew DHCP lease (useful if you're stuck on a bad address): ipconfig /release ipconfig /renew
# Show/clear the DNS cache on Windows: ipconfig /displaydns ipconfig /flushdns
If you ever see an address starting with 169.254.x.x, DHCP failed — the OS auto-assigned itself a link-local address because it couldn't get one from a DHCP server. This is an instant clue that something's wrong with the network or router. (cross-reference: Ch 6 DHCP section.)
18.6 netstat / ss — Who's Connected
Shows the active network connections and listening ports on your machine. Useful for checking what's talking to what.
netstat -ano# Windows: all connections + process IDs netstat -tulpn# Linux: all listening/established with PIDs ss -tulpn# Modern Linux equivalent
Typical output:
Proto Local Address Foreign Address State PID
TCP 192.168.1.42:52341 142.250.76.78:443 ESTABLISHED 4312
TCP 192.168.1.42:52342 13.107.42.12:443 ESTABLISHED 4312
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 768
TCP 192.168.1.42:52410 52.97.188.34:443 ESTABLISHED 8204
Read this as: "the browser (PID 4312) has connections to various :443 ports (HTTPS) on various remote IPs." The LISTENING state means the local machine is accepting incoming connections on that port — a service running locally.
DEFENSIVE USE: If malware is phoning home, you may see it here as an outbound connection from a suspicious process to a weird IP. Tools like Sysinternals TCPView show this in a nicer GUI than raw netstat. This is a basic IR triage step — "what's connected?" and "what processes are making those connections?"
18.7 nmap — Port Scanning (Use Responsibly)
nmap is the industry-standard port scanner. It tells you what TCP/UDP ports are open on a target and can fingerprint services and operating systems.
WARNING: nmap is legal to use only on systems you own or have explicit permission to scan. Scanning other networks — your school, a business, random internet hosts — can breach the Cybercrime Act 2001 as unauthorised access or impairment. In Australia, this is enforced. Only practise against your own machine (nmap 127.0.0.1), a VM you set up, or designated practice sites (scanme.nmap.org — explicitly authorised).
# Scan your own machine — safe and instructive: nmap 127.0.0.1
# The official legal-practice target: nmap scanme.nmap.org
# Common flags: nmap -sV target# detect service versions nmap -O target# attempt OS detection nmap -p 80,443 target# scan specific ports only
Typical output looks like:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
3306/tcp open mysql
The attacker's perspective: open ports are potential targets. The defender's perspective: what's open on my own systems that I didn't intend to expose? Both are valid uses, and both matter. A routine self-scan of your own perimeter catches accidental exposures — forgotten services, misconfigurations — that would otherwise be found by attackers.
18.8 Wireshark — Actually Seeing the Packets
Wireshark is a free GUI packet capture tool. It records every packet your network card sees, decodes them, and displays them in a readable form. It's the most powerful networking tool in this list and the one most worth playing with.
A basic workflow:
Install Wireshark from wireshark.org
Choose your active network interface (Wi-Fi or Ethernet)
Start capture
Visit a website in your browser
Stop capture
Browse the thousands of packets you just collected
You'll immediately see:
The DNS query for the site's name — and the response with the IP
The TCP three-way handshake (SYN, SYN-ACK, ACK)
The TLS handshake for HTTPS — certificate exchange visible but encrypted application data after
HTTP/HTTPS requests flowing back and forth
Seeing encapsulation visually — each packet wrapping its payload through Layers 2, 3, 4, 7 — is what makes the OSI model click for most students. (cross-reference: Ch 4 encapsulation diagram.)
LEGAL NOTE: Capturing your own traffic on your own network is fine. Capturing other people's traffic without consent — e.g., running Wireshark in "promiscuous mode" on a public Wi-Fi — may breach the Telecommunications (Interception and Access) Act 1979. Stick to your own traffic unless you're in a controlled practice lab.
18.9 Putting It All Together — A Diagnostic Workflow
When "the internet doesn't work," a professional's debugging sequence typically goes:
ipconfig — do I have a valid IP address? Is my gateway set? (If 169.254 — DHCP failed.)
ping 192.168.1.1 (or your gateway) — can I reach my router?
ping 8.8.8.8 — can I reach the internet at all (IP level)?
ping google.com — does DNS work? (If step 3 works but step 4 fails, DNS is broken.)
tracert google.com — where is the packet getting stuck?
nslookup google.com — confirm DNS resolution details
netstat — is anything weird going on with connections?
This workflow walks up the OSI stack: physical connectivity → network layer (IP) → transport (TCP) → application (DNS/HTTP). Tracing where the chain breaks identifies the problem layer. (cross-reference: Ch 4 layer model — the layered mental model applies directly to debugging.)
EXAM PATTERN: When asked "how would you investigate a connectivity problem?" or "what tool would you use to check X?", match the tool to the layer:
- Physical connectivity → check cables, LEDs, router
- IP addressing → ipconfig
- Basic reachability → ping
- Path issues → tracert
- DNS → nslookup
- Active connections → netstat
- Open ports (of your own) → nmap with authorisation
- Packet-level → Wireshark
Matching tool-to-problem precisely shows you understand both the tools and the layers.
18.10 Quiz Time
A user reports "the internet is slow." You run ping to google.com and get 300ms latency. You run ping to your home router and get 2ms latency. What's the likely problem and which tool would you use next?
The home network is fine (2ms to the router). The slow response to google.com means the slowness is somewhere beyond your router — on the way to Google. Next step: tracert google.com. The hop where latency suddenly jumps tells you where the delay is happening — typically your ISP's network or a backbone router further out. If every hop is slow, it's your ISP uplink; if one specific hop is the culprit, you've localised the problem. Not much you can fix in your ISP's network, but you can report it with evidence.
Why is running nmap against a company's website (not your own) potentially illegal in Australia?
Port scanning is considered unauthorised access under the Cybercrime Act 2001 — specifically, the act of probing a system you don't own without the owner's explicit permission. Even if no damage results and the data obtained is technically public-facing, the unauthorised probing is the offence. Companies often log and alert on scans, and repeated or aggressive scans can trigger complaints. The legal principle is identical to physical security — even "just checking if the door is unlocked" on someone else's property is trespass. Use nmap only against your own systems, designated practice targets (scanme.nmap.org), or systems you have written authorisation to test. (In exam terms: authorisation must exist before the probe, not after.)
You see a suspicious email from a bank. You want to check if the sender's domain is legitimately that bank's. Which tools would you use and what are you looking for?
1. nslookup -type=MX on the sender's domain — compare to the bank's real domain. Mismatch is a red flag. 2. nslookup -type=TXT on the sender's domain — look at SPF/DKIM/DMARC records. Legitimate banks publish these; phishing domains often don't. 3. nslookup on any links in the email — do they resolve to the bank's real IPs, or to a random hosting provider? 4. WHOIS (online) — when was the domain registered? Phishing domains are often only days or weeks old.
All of this is read-only and fully legal. Never click the links in a suspicious email to "investigate" — that's the attacker's goal. Report the email to the bank's fraud address and then to ReportCyber.
You run ipconfig and see your IP as 169.254.12.45. What does this mean?
Your device failed to get an IP address from DHCP and fell back to APIPA / link-local addressing (the 169.254.0.0/16 range). Possible causes:
(1) the DHCP server on the network is down or unreachable;
(2) the network isn't providing DHCP (some corporate networks require static addresses);
(3) a network cable or Wi-Fi association is up at Layer 2 but broken further up (modem problem, ISP outage);
(4) rogue DHCP server is interfering.
Fixes to try: ipconfig /release then ipconfig /renew, reboot the router, check for cabling issues, or check whether other devices on the same network have the same problem (helps pinpoint client vs network). (Cross-reference: Ch 6 DHCP section on DORA and rogue DHCP.)