Computer Networking Cheatsheet
Troubleshooting Commands
Use this Computer Networking reference while you build software engineering projects, review code, or refresh the syntax you reach for most.
What each tool proves
Pick the tool by the layer you are testing, and know exactly what a green result rules out.
| Command | Layer | Proves | Does not prove |
|---|---|---|---|
ip link | 1-2 | the NIC is up and has carrier | anything about addressing |
ip addr | 3 | an address is configured | that it is reachable |
ip neigh | 2 | the peer answers ARP or NDP on this link | routing beyond the link |
ip route get | 3 | which route and interface will be used | the path actually works |
ping | 3 | end-to-end IP reachability, RTT, loss | the port or service is up |
traceroute · mtr | 3 | the path and where loss begins | that the app will respond |
ss | 4 | who listens locally, socket states | reachability from outside |
nc -vz | 4 | the TCP port accepts a connection | the protocol behind it works |
dig | 7 | name resolution and which resolver answered | that /etc/hosts agrees |
curl -v | 7 | full request, TLS, headers, status | anything below if it succeeds |
tcpdump | 1-7 | what is actually on the wire | intent, only observed bytes |
Work bottom up when nothing works, top down when something half-works.
Interfaces, addresses, and neighbours
ip -br link # brief: name, state, MAC ip -br addr # brief: name, state, addresses ip -s link show eth0 # counters: errors, drops, overruns ip addr show dev eth0 ip neigh show dev eth0 # ARP/NDP cache with states ip neigh flush dev eth0 ethtool eth0 # speed, duplex, carrier ethtool -S eth0 | grep -iE 'err|drop' ip link set eth0 up
LOWER_UP in ip link means the cable or radio has carrier. NO-CARRIER is a
physical problem and no amount of IP configuration will fix it.
Routing and reachability
ip route # the table ip route get 8.8.8.8 # the decision for one destination ip route get 10.0.5.9 from 10.0.1.4 # source-aware, catches policy rules ip rule show # policy routing rules ping -c 4 192.168.1.1 # the gateway first, always ping -c 4 -I eth0 8.8.8.8 # pin the source interface ping -c 4 -i 0.2 -W 1 8.8.8.8 # faster interval, 1 s timeout ping -M do -s 1472 8.8.8.8 # path MTU probe, DF set ping -c 4 example.com # if this fails but the IP works, it is DNS traceroute 8.8.8.8 # UDP probes (default on Linux) traceroute -I 8.8.8.8 # ICMP echo probes traceroute -T -p 443 example.com # TCP SYN, best through firewalls traceroute -n 8.8.8.8 # skip reverse DNS, much faster mtr -rwc 50 8.8.8.8 # report mode, 50 cycles, wide mtr -T -P 443 example.com # TCP mode tracepath example.com # per-hop MTU, no root needed
Reading mtr: loss at an intermediate hop that clears at later hops is ICMP
rate limiting on that router, not a fault. Only loss that persists to the final
hop is real. Rising latency at one hop that stays flat afterwards is also
harmless.
Sockets, ports, and processes
ss -tulpn # listening TCP+UDP with process names ss -tan # all TCP sockets with states ss -tan state established ss -tan state time-wait | wc -l ss -tp 'dport = :443' # connections to a port, with the owning PID ss -ti # per-socket rtt, cwnd, retransmits ss -s # summary counts by protocol and state lsof -iTCP:8080 -sTCP:LISTEN # who holds a port (macOS friendly) lsof -i @10.0.0.5 # sockets to one host fuser -k 8080/tcp # kill whatever holds the port
| Observation | Interpretation |
|---|---|
Nothing in ss -tulpn for your port | the process is not listening, check logs |
Listening on 127.0.0.1 only | unreachable from other hosts, bind 0.0.0.0 |
Many CLOSE_WAIT | your app is not calling close(), a descriptor leak |
Many TIME_WAIT on a client | normal, unless the ephemeral range is exhausted |
Many SYN-RECV | SYN flood, or the backlog is too small |
Probing a port from outside
nc -vz example.com 443 # single TCP port, open or refused or timeout nc -vzu 10.0.0.1 53 # UDP, unreliable by nature nc -l 9000 # listen, to test the other direction timeout 3 bash -c '</dev/tcp/example.com/443' && echo open # no nc needed nmap -Pn -p 22,80,443 --reason 10.0.0.5 nmap -sn 192.168.1.0/24 # who is alive in the subnet nmap -sU -p 53,123 10.0.0.1 # UDP scan, slow curl -v https://example.com curl -sS -o /dev/null -w \ 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} \ ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \ https://example.com curl --resolve example.com:443:203.0.113.9 -sSI https://example.com openssl s_client -connect example.com:443 -servername example.com </dev/null
That curl -w timing breakdown localizes slowness in one shot: a big
time_namelookup is DNS, a big time_connect is the network or a saturated
backlog, a big time_appconnect is TLS, and a big time_starttransfer is the
application.
| Probe result | Means |
|---|---|
succeeded / open | reachable and listening |
Connection refused | host reached, nothing listening (or an explicit REJECT) |
times out / filtered | a DROP rule or a black-hole route |
No route to host | ARP or routing failure, not a firewall |
Name or service not known | DNS, not connectivity |
DNS checks
dig +short example.com dig +trace example.com # walk the delegation dig @1.1.1.1 example.com # bypass the local resolver dig @ns1.example.com example.com # ask authoritative, skip all caches dig -x 203.0.113.9 +short # reverse resolvectl status # which resolver each link uses resolvectl query example.com getent hosts example.com # honors /etc/hosts, unlike dig grep -v '^#' /etc/hosts
If getent and dig disagree, the answer is in /etc/hosts or in nsswitch, not
in DNS.
Packet capture
tcpdump -D # list capture interfaces tcpdump -ni any port 443 # no name resolution, all interfaces tcpdump -ni eth0 host 10.0.0.5 and tcp port 5432 tcpdump -ni eth0 'tcp[tcpflags] & (tcp-syn|tcp-rst) != 0' # setup and resets tcpdump -ni eth0 icmp or icmp6 tcpdump -ni eth0 -e vlan # show L2 headers and VLAN tags tcpdump -ni eth0 -A port 80 # print payload as ASCII tcpdump -ni eth0 -c 200 -w cap.pcap # write for Wireshark tcpdump -r cap.pcap -nn -tttt # read back with timestamps tshark -r cap.pcap -q -z conv,tcp # conversation summary
Interpretation shortcuts: SYN out with no SYN-ACK back means the packet is not arriving or the reply is blocked. SYN answered with RST means nothing is listening. Repeated identical sequence numbers are retransmissions, so the path is losing packets. Nothing at all on the wire means the traffic never left the host, so look at routing and local firewall rules.
Throughput and latency measurement
iperf3 -s # on the server iperf3 -c 10.0.0.5 -t 30 # TCP throughput iperf3 -c 10.0.0.5 -u -b 200M # UDP at a fixed rate, shows jitter/loss iperf3 -c 10.0.0.5 -P 8 # 8 parallel streams iperf3 -c 10.0.0.5 -R # reverse, tests download nstat -az | grep -iE 'retrans|drop' ss -ti | grep -E 'rtt|retrans' sar -n DEV 1 5 # per-interface throughput over time
A single TCP stream that underperforms while eight parallel streams saturate the link points at window scaling, latency, or loss rather than raw bandwidth. Recompute the bandwidth-delay product before blaming the network.
A repeatable triage order
1. ip -br link and ip -br addr, is the interface up with an address?
2. ping <default gateway>, is layer 2 and 3 working on the local link?
3. ip route get <target>, will the packet take the route you expect?
4. ping <target IP>, is the far host reachable at all?
5. dig <target name>, does the name resolve to that IP?
6. nc -vz <target> <port>, is the port open?
7. curl -v with the timing format, does the application answer, and where is
the time going?
8. tcpdump on both ends, only if the layers above disagree with each other.
Change one variable at a time, and record what you ran. Most "network problems" resolve at step 5 or 6.