← Home

Field Guide Collection · Reference

Diagnostic
Command Card

Copy-ready checks grouped by what you're trying to find out, across Linux, Windows, macOS, and Cisco IOS. Replace HOST, PORT, IF as needed. Command flags vary by OS version — if one is rejected, verify it against your platform rather than assuming the check is wrong. This card stands on its own; the concepts are in the guides, the terms in the Glossary.

11 checks 4 platforms stop at first failure

Order of attack: local config → reachability → path → DNS → port → TLS → MTU → counters → capture. Stop bisecting the moment a rung fails — that failure names the layer to work. Each check tells you one thing; be precise about what it does and doesn't prove.

01

Local Configuration & Identity

Before blaming the network, confirm what the host thinks it is — addresses, mask, gateway, resolver, and the route it would actually pick.

# Linux ip addr ; ip route ; ip neigh # addresses, routes, ARP/ND cache resolvectl status # which DNS resolver(s) are actually in use ip route get 8.8.8.8 # which route/gateway a dest WOULD use # Windows (PowerShell) ipconfig /all # addresses, mask, gateway, DNS route print ; arp -a Get-DnsClientServerAddress # configured resolvers Find-NetRoute -RemoteIPAddress 8.8.8.8 # route a dest would use # macOS ifconfig ; netstat -rn ; arp -a scutil --dns # resolver configuration # Cisco IOS show ip interface brief show ip route show ip arp
02

Reachability (ICMP Only)

# Linux / macOS ping -c4 HOST # Windows ping HOST # 4 by default; -t for continuous # Cisco IOS ping HOST

Test in order: loopback → own IP → default gateway → next hop → remote host. The first failure marks your segment. Ping proves ICMP reachability and rough round-trip time only — not that a port or an application works, and ICMP may be filtered even where the service is fine.

03

Path — Where Does It Break?

# Linux / macOS traceroute HOST mtr HOST # continuous per-hop loss + latency (best for intermittent) # Windows tracert HOST pathping HOST # traceroute + per-hop loss over time # Cisco IOS traceroute HOST
Read it right

A latency spike at a middle hop that doesn't carry through to the destination is usually the router de-prioritizing ICMP to its own control plane — not real forwarding latency. Only loss or latency that persists to the final hop is real. mtr / pathping beat a single traceroute for intermittent loss because they sample over time.

04

DNS Resolution

The question is always: which resolver answered, and does it match the authoritative truth?

# Linux / macOS dig HOST # what my resolver returns dig HOST +short dig HOST NS +short # who is authoritative dig @AUTH_NS HOST # ask the authoritative server directly (bypass caches) dig @9.9.9.9 HOST # compare against a public resolver dig HOST +trace # full delegation from the root dig -x 203.0.113.10 # reverse (PTR) # Windows Resolve-DnsName HOST nslookup HOST nslookup HOST AUTH_NS # query a specific server
Reading the status

NOERROR + answer = resolved. NXDOMAIN = the name doesn't exist (and this negative result is itself cacheable). NOERROR + no answer = the name exists but not for that record type (e.g. an AAAA query for an A-only name). SERVFAIL = resolver, upstream, or DNSSEC failure. Timeout = the resolver itself is unreachable (wrong address, or udp/53 & tcp/53 blocked).

05

Port / Service Reachability

# Linux / macOS nc -vz HOST PORT # TCP connect test nc -vzu HOST PORT # UDP (weaker signal — no handshake) curl -v http://HOST:PORT/ # see the actual exchange # Windows Test-NetConnection HOST -Port PORT # TcpTestSucceeded: True / False
Result → meaning

SYN-ACK / "succeeded" = port open, service listening. RST / "connection refused" = host reachable, no listener on that port (service down, wrong port, or bound to loopback). Timeout = filtered by a firewall, or the host is down — ambiguous. A fast refused is informative; a timeout is not.

06

TLS / Certificates

# any platform with curl / openssl curl -v https://HOST/ # plain-language verify errors openssl s_client -connect HOST:443 -servername HOST # full handshake + chain # validity dates + SAN of the presented leaf openssl s_client -connect HOST:443 -servername HOST </dev/null 2>/dev/null \ | openssl x509 -noout -dates -subject -ext subjectAltName
What to check

Chain complete (is the intermediate present?), verify return code: 0, dates valid — and the client clock is right, since skew fakes an "expired" error on a good cert. The leaf's SAN must cover the hostname, and -servername (SNI) must match what you're testing. A failure before application data is version/cipher/cert; a failure after a good handshake is an application problem, not TLS.

07

MTU / Fragmentation

The signature is "small works, large hangs." Set the don't-fragment bit and grow the payload until it stops passing.

# Linux ping -M do -s 1472 HOST # DF set; 1472 + 28 = 1500 # macOS ping -D -s 1472 HOST # -D = don't fragment # Windows ping -f -l 1472 HOST # -f = DF, -l = payload size
The arithmetic

The largest payload that passes + 28 (20-byte IP header + 8-byte ICMP header) is your path MTU. Tunnels and VPNs lower it. If large packets vanish with no error at all, suspect a PMTUD black hole — the ICMP that should signal "too big" is being filtered — and fix it with unblocked ICMP or MSS clamping.

08

Interface Counters & Errors

# Linux ip -s link show IF ; ethtool IF ; ethtool -S IF # errors, drops, duplex, speed netstat -i # macOS: Ierrs / Oerrs # Windows Get-NetAdapterStatistics ; Get-NetAdapter | fl # Cisco IOS show interfaces IF # CRC, input/output errors, late collisions, duplex show interfaces status # speed / duplex / VLAN at a glance

CRC/FCS errors + late collisions + poor throughput point to a duplex mismatch or bad cabling. Rising input drops point to oversubscription or buffer exhaustion, not a physical fault.

09

Connections & Listeners

# Linux ss -tlnp # listening TCP + owning process ss -tan # all TCP with states ss -tan state time-wait | wc -l # count TIME_WAIT # Windows Get-NetTCPConnection | ? State -eq Listen # listeners netstat -ano
Bind address decides remote reachability

A service bound to 127.0.0.1 / ::1 is loopback-only and will refuse remote clients with a RST; 0.0.0.0 / :: is all interfaces. "Works locally, refused remotely" → check the bind address first. Many CLOSE-WAIT usually means the local app isn't closing sockets; many SYN-SENT means outbound connects aren't completing (filtered or down).

10

Throughput

# on the server host iperf3 -s # on the client host iperf3 -c SERVER # achievable throughput, single stream iperf3 -c SERVER -P 8 # parallel streams

Ping is not throughput. If a single stream is slow on a high-bandwidth, high-RTT path but parallel streams saturate it, the limiter is the TCP window / bandwidth-delay product (window scaling), not the link. If even parallel streams can't fill it, the link or a policer is the ceiling.

11

Packet Capture — Ground Truth

# Linux / macOS — targeted, then save for Wireshark tcpdump -ni IF host HOST and port PORT tcpdump -ni IF host HOST -w /tmp/cap.pcap # Windows pktmon start --capture ; pktmon stop # or: netsh trace

Capture as close to the problem as possible and filter tightly — a capture only sees what crossed that point, so absence of a packet is not proof the event didn't happen. When opinions conflict, the pcap decides (see the Packet Capture guide for reading one, and for decrypting your own TLS with SSLKEYLOGFILE).

12

Reference — What Normal Looks Like

Baselines and fingerprints for reading the results above. Treat the values as common defaults, not guarantees — most are configurable.

You seeIt means
SYN-ACK / "succeeded"Port open, service listening.
RST / "connection refused"Host reachable, no listener on that port.
Timeout / no responseFiltered (firewall drop) or host down — ambiguous.
ICMP echo replyHost up at L3; says nothing about ports or apps.
ICMP "administratively prohibited"A firewall actively rejected it.
TCP states worth recognizing (ss / netstat)

LISTEN (waiting) · SYN-SENT / SYN-RECV (handshake in progress) · ESTABLISHED (open) · FIN-WAIT / CLOSE-WAIT / LAST-ACK (closing) · TIME-WAIT (normal post-close wait on the side that closed first). Lots of CLOSE-WAIT → the local app isn't closing sockets; lots of SYN-SENT → outbound connects failing.

Common well-known ports

Stable defaults — many services are reconfigurable, so verify anything beyond these against IANA/vendor docs: 20/21 FTP · 22 SSH · 23 Telnet · 25 SMTP · 53 DNS (UDP and TCP) · 67/68 DHCP · 80 HTTP · 88 Kerberos · 110 POP3 · 123 NTP · 143 IMAP · 161/162 SNMP · 389 LDAP · 443 HTTPS · 445 SMB · 465/587 SMTP submission · 636 LDAPS · 993 IMAPS · 995 POP3S · 500/4500 IKE/IPsec NAT-T · 3389 RDP. Often-changed app defaults: 3306 MySQL · 5432 PostgreSQL · 1433 MSSQL · 6379 Redis · 27017 MongoDB.

Fingerprints & ballparks

Ephemeral (client source) ports: IANA 49152–65535; Linux often 32768–60999; Windows ~49152–65535. Stateless return rules must permit the range your clients actually use. Initial TTL / hop-limit (common defaults, configurable): Linux/Unix/macOS ≈ 64, Windows ≈ 128, many network devices ≈ 255 — a reply's TTL hints at the responder's OS and hop distance. Latency sanity-check (not targets): same LAN under 1 ms; same metro single-digit ms; cross-continent tens of ms; intercontinental ~100–300 ms. Far above these for the distance → investigate.

Ported from the collection's networking source notes. Command flags vary by OS and version — verify a rejected flag against your platform rather than assuming the check is wrong. Port numbers, TTL defaults, and ephemeral ranges are common defaults and are configurable; confirm anything load-bearing against IANA or vendor documentation. No output on this card is a security verdict: a reachable port is not a safe service, and a check that passes reflects that check's narrow scope, not the health of the system. Pairs with the Triage Decision Trees (which check to run when) and the Network "Follow the Packet", DNS-and-TLS coverage within it, Packet Capture, and Vulnerability Management guides; terms are in the Glossary, and 00 · Start Here indexes the set.