Network tools

Networking advice is easy to repeat and easy to get wrong. A few command-line tools let you check the claims yourself. Use ping for the round-trip floor, mtr for the path, ss for live connection state, and tcpdump for the packets.

ping: the round-trip floor

ping sends ICMP echo requests and reports RTT. It is the fastest way to learn the RTT floor to a host and whether packets are being lost.

$ ping -c 4 example.com
64 bytes from 93.184.215.14: icmp_seq=1 ttl=56 time=78.2 ms
...
4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max/mdev = 77.9/78.3/78.9/0.4 ms

Many cloud load balancers drop ICMP, so no reply does not always mean the host is down.

traceroute and mtr: the path

traceroute sends packets with TTL 1, 2, 3 and so on. Each router that decrements the TTL to zero sends back an ICMP "time exceeded" message, which reveals it. mtr does the same thing continuously and shows loss and latency for each hop.

When you read mtr, look for the hop where latency jumps and stays high. One hop showing loss while later hops do not is usually a router that deprioritizes ICMP. That is not a real problem.

ss: live socket state

ss (the modern replacement for netstat) lists sockets. It is the quickest way to see what is open right now.

$ ss -tan state time-wait | wc -l        # count TIME_WAIT sockets
$ ss -tni dst 10.0.4.12                  # kernel's live view of each connection
ESTAB 0 0 10.0.1.5:51234 10.0.4.12:5432
   cubic wscale:7,7 rto:204 rtt:1.2/0.3 mss:1448 cwnd:10 bytes_acked:5821 retrans:0/0

The -ti view includes RTT, the congestion window (cwnd) and retransmission counts. A rising retrans count points to packet loss on that path.

tcpdump: the packets

tcpdump captures packets, and Wireshark shows them visually. Here is a capture of a handshake and a plain-HTTP request:

$ sudo tcpdump -i any -nn 'tcp port 80 and host 93.184.215.14'
10:01:00.000 IP 10.0.1.5.51234 > 93.184.215.14.80: Flags [S], seq 1000, win 64240, options [mss 1460,sackOK,TS,nop,wscale 7]
10:01:00.078 IP 93.184.215.14.80 > 10.0.1.5.51234: Flags [S.], seq 5000, ack 1001, win 65535, options [mss 1460,...]
10:01:00.078 IP 10.0.1.5.51234 > 93.184.215.14.80: Flags [.], ack 5001
10:01:00.079 IP 10.0.1.5.51234 > 93.184.215.14.80: Flags [P.], seq 1001:1078, ack 5001  (GET / HTTP/1.1)
10:01:00.157 IP 93.184.215.14.80 > 10.0.1.5.51234: Flags [.], seq 5001:6449, ack 1078

Read it line by line. [S] is the SYN. [S.] is the SYN-ACK, 78 ms later, which is the RTT. [.] is the ACK. [P.] pushes the 77-byte request. The first byte of the response arrives one more RTT later. The handshake's cost is visible in the timestamps.

Save captures with -w capture.pcap and open them in Wireshark. Its "Statistics → TCP Stream Graphs → Time Sequence" view shows slow start as a staircase.

Walking through it: a checking routine

When someone says "the network is slow", run these in order:

1. ping the host to get the RTT floor. If the floor is high, round trips are the cost.
2. mtr to the host, to see whether a hop in the middle is losing packets.
3. ss -tni on the client to see cwnd, RTT and retrans for live connections.
4. tcpdump a single connection if the numbers still do not explain the delay.

Common mistakes

• Reading ICMP loss as real loss. Routers often deprioritize ICMP. Check application-level loss too.
• Running tcpdump on a busy host without a filter. Filter by host and port, or the capture floods the disk.
• Assuming one ping tells you the whole story. Run it several times, and look at the variance too.

Check yourself

• In the capture above, how do you know the RTT is about 78 ms? The gap between the SYN at 10:01:00.000 and the SYN-ACK at 10:01:00.078.
• What does a rising retrans count in ss -ti suggest? Packet loss on that path, which triggers retransmissions.

Key takeaways

• ping gives the RTT floor. mtr shows where on the path the time or loss sits.
• ss -tni shows live cwnd, RTT and retransmits for each connection.
• tcpdump captures packets, and the timestamps between SYN and SYN-ACK measure the RTT directly.
• Check your claims with these tools before changing configuration.

Further learning

Revisit networking basics for the layers and vocabulary these tools display, or go to TCP handshake and reliability to see each handshake step in context.