ICMP, Ping and Traceroute

By the end of this lesson you will be able to

• Explain what ICMP is for and recognise its main message types: Echo, Destination Unreachable (and its codes), Redirect and Time Exceeded.
• Run ping, read every number in its output (time, ttl, packet loss, min/avg/max/mdev) and know why a failed ping does not always mean a site is down.
• Explain how traceroute uses the TTL trick, compare the UDP, ICMP and TCP variants, and read its output, including * * * lines and misleading latency spikes.
• Tell latency, bandwidth, jitter and packet loss apart.
• Explain Path MTU Discovery and why “block all ICMP” breaks large transfers.
• Follow a step-by-step troubleshooting ladder from your own computer to the application.
• For one failing service, go layer by layer (link → IP → gateway → DNS → port → TLS → HTTP) with the right command at each step, and recognise the symptom that points at each layer.
• Estimate the minimum round trip between two places from the speed of light in fibre, and explain why servers and CDNs are placed near users.

#ICMP: the network’s messenger

ICMP (Internet Control Message Protocol) is a support protocol of the network layer (Layer 3 in the OSI model). It is not used to carry ordinary data or web pages. Its job is to report problems and help with diagnostics: “that destination is unreachable”, “this packet’s TTL ran out”, “are you there? yes, I am”.

A few facts that explain a lot of its behaviour:

• ICMP messages travel directly inside IP packets (IP protocol number 1). There is no TCP or UDP underneath, so ICMP has no ports. Instead each message has a type and a code.
• Routers and hosts generate ICMP automatically when something goes wrong. An error message includes the first bytes of the packet that caused it, so the sender can tell which connection it belongs to.
• IPv6 has its own version, ICMPv6, which is even more essential: IPv6 neighbour discovery (its replacement for ARP) runs on it.

#The message types you will meet

The most useful codes of type 3:

In ICMPv6 the numbers differ: Echo Request is 128, Echo Reply 129, Destination Unreachable 1, Packet Too Big 2 and Time Exceeded 3.

#Ping: “is anyone there?”

Ping is the most basic command for checking whether two devices can reach each other and how long the round trip takes.

How it works:

1. The client sends an ICMP Echo Request (type 8) to the target IP address.
2. If the target is up and allowed to answer, it replies with an ICMP Echo Reply (type 0), copying back the identifier, sequence number and data.

What it tells you:

• RTT (Round Trip Time): in milliseconds (ms), how long the packet took to go and come back.
• Packet loss: what percentage of requests never got a reply.

# Command format
ping google.com

#Reading ping output

Linux and macOS keep pinging once per second until you press Ctrl+C:

$ ping -c 4 google.com
PING google.com (142.250.190.46) 56(84) bytes of data.
64 bytes from 142.250.190.46: icmp_seq=1 ttl=117 time=23.1 ms
64 bytes from 142.250.190.46: icmp_seq=2 ttl=117 time=22.8 ms
64 bytes from 142.250.190.46: icmp_seq=3 ttl=117 time=23.3 ms
64 bytes from 142.250.190.46: icmp_seq=4 ttl=117 time=22.9 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 22.8/23.0/23.3/0.2 ms

Windows sends 4 requests by default and words it differently:

> ping google.com
Reply from 142.250.190.46: bytes=32 time=23ms TTL=117
Request timed out.
Reply from 142.250.190.46: bytes=32 time=24ms TTL=117
Reply from 142.250.190.46: bytes=32 time=22ms TTL=117

Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Minimum = 22ms, Maximum = 24ms, Average = 23ms

#Useful ping options

#Latency, bandwidth, jitter and loss are different things

A link can have huge bandwidth and terrible latency (a satellite link), or low latency and little bandwidth. Ping only measures latency, jitter and loss, never bandwidth.

#When ping fails but the site works

A failed ping is a hint, not a verdict:

• ICMP is blocked. Many firewalls and cloud security groups (AWS blocks it by default) drop Echo Requests while allowing TCP 443. Ping shows 100% loss and the website loads perfectly.
• The name did not resolve. “could not find host” or “Name or service not known” means DNS failed; ping never sent a packet.
• ICMP is rate-limited or deprioritised. Routers answer ICMP with low priority, so ping times to a router can look worse than real traffic through it.

To test the real service, test the real protocol: curl -I https://example.com, or on Windows Test-NetConnection example.com -Port 443.

#Traceroute: mapping the path

Traceroute (tracert on Windows) shows which routers (hops) a packet passes through on its way from your computer to the destination, and where the delay builds up.

  [My computer] ──(TTL=1)──► [Router 1] ──► (Time Exceeded)
  [My computer] ──(TTL=2)──► [Router 1] ──► [Router 2] ──► (Time Exceeded)
  [My computer] ──(TTL=3)──► [Router 1] ──► [Router 2] ──► [Server] ──► (Echo Reply / Port Unreachable)

#The TTL trick

Traceroute deliberately exploits the TTL field in the IP header:

1. TTL = 1: the first probe is sent with TTL 1. The first router decrements it to 0, drops the packet and sends back ICMP Time Exceeded (type 11). That message comes from the router’s own IP address, so your computer now knows the first hop.
2. TTL = 2: the second probe passes the first router and dies at the second, which reveals itself the same way.
3. TTL keeps increasing by one until a probe reaches the destination itself, which answers in a different way (Echo Reply or Port Unreachable). Then traceroute stops.

It sends three probes per hop by default, which is why each line shows three times, and gives up after 30 hops.

#UDP, ICMP and TCP traceroute

The TTL trick is the same everywhere; what differs is the kind of probe:

When firewalls near the destination block UDP and ICMP probes, the TCP variant to port 443 usually gets through, because that is the port the service must allow.

#Reading traceroute output

$ traceroute example.com
traceroute to example.com (198.51.100.20), 30 hops max, 60 byte packets
 1  192.168.1.1     1.2 ms   1.0 ms   1.1 ms
 2  203.0.113.1     6.8 ms   7.1 ms   6.9 ms
 3  * * *
 4  192.0.2.17     22.5 ms  22.1 ms  22.8 ms
 5  198.51.100.20  23.0 ms  22.9 ms  23.2 ms

• Hop 1 is your own router, a millisecond or two away. Hop 2 is usually your ISP.
• * * * means no reply came back within the timeout for any of the three probes. A single silent hop in the middle (hop 3 here) is harmless: that router just does not send Time Exceeded, or rate-limits it. Packets clearly pass it, because hops 4 and 5 answer. Only stars that continue to the end suggest the destination or a firewall in front of it is filtering probes.
• A latency spike at one hop that disappears at the next is not a problem. Routers forward traffic in fast hardware but create ICMP replies in a slow, low-priority control plane. Only latency (or loss) that persists to the final hop is real.
• A big jump between two hops that persists usually means a long physical distance, for example when traffic leaves Bangladesh for Singapore or Europe, or congestion on that link.
• Traceroute shows only the outbound path. The replies may come back a different way (asymmetric routing), so a slow hop can actually be a slow return path.
• Add -n (Linux) or -d (Windows) to skip reverse DNS lookups and get results faster.

#mtr and pathping: traceroute that keeps going

A traceroute is a single snapshot. mtr (Linux/macOS, and WinMTR on Windows) combines ping and traceroute and keeps probing every hop, updating loss and latency statistics live. pathping on Windows does the same in one go: it traces the route, then pings every hop 100 times (roughly 25 seconds per hop) and reports loss per hop.

mtr example.com               # live view
mtr -rwc 100 example.com      # report after 100 rounds (good to paste into a ticket)
pathping example.com          # Windows

Read mtr the same way: loss shown at one middle hop but not at later hops is that router rate-limiting ICMP; loss that starts at a hop and continues to the destination is real.

#Path MTU Discovery: when ICMP must not be blocked

Every link has an MTU (maximum transmission unit), usually 1500 bytes on Ethernet but less on tunnels and VPNs. Modern TCP stacks set the DF (Don’t Fragment) bit, so routers may not split oversized packets. Instead:

1. A router whose next link is too small drops the packet.
2. It sends ICMP Destination Unreachable, code 4 (fragmentation needed), including the next-hop MTU.
3. The sender lowers its packet size for that destination and resends.

That is Path MTU Discovery (PMTUD). In IPv6, routers never fragment at all and send ICMPv6 Packet Too Big (type 2).

If a firewall “blocks all ICMP for security”, the sender never hears that its packets are too big. The result is a PMTUD black hole: the TCP handshake and small requests work, but large pages, downloads and uploads hang until they time out. It is one of the most confusing faults in networking. The fixes are to allow ICMP type 3 (and ICMPv6 type 2), or to have the router lower the MSS in TCP handshakes (MSS clamping), which VPNs and home routers commonly do.

You can find the path MTU yourself: ping -M do -s 1472 example.com on Linux (1472 bytes of data + 28 bytes of headers = 1500) or ping -f -l 1472 example.com on Windows. If you get “message too long” or “Packet needs to be fragmented but DF set”, lower the size until it passes.

#A troubleshooting ladder

When someone says “the internet is down”, test one layer at a time, starting nearest to you. The first step that fails tells you where to look.

1. 1. Do I have an address?

   ipconfig (Windows) or ip addr (Linux/macOS). You should see an address like 192.168.1.10 and a default gateway. A 169.254.x.x address means DHCP failed: the problem is between you and the router.

2. 2. Can I reach my gateway?

   ping 192.168.1.1 (your gateway). Replies should take 1–5 ms. If this fails, the problem is local: Wi-Fi signal, wrong network, cable, or the router itself.

3. 3. Can I reach the internet by IP?

   ping 8.8.8.8 (or 1.1.1.1). Using an IP address skips DNS, so this tests only routing through your ISP. If the gateway answers but this fails, the ISP link is down.

4. 4. Does DNS work?

   nslookup example.com. If pinging an IP works but names fail, the problem is DNS. Try another resolver directly (nslookup example.com 1.1.1.1), then change the DNS server or flush the cache.

5. 5. Does the service itself work?

   curl -I https://example.com or Test-NetConnection example.com -Port 443. The way it fails is the clue: “connection refused” means the host is up but nothing listens on that port; a timeout means a firewall or a dead host; an HTTP 502/503 means the server answered but its backend is broken; a certificate error points to TLS. If everything up to here worked, your network is fine and the problem is the service, so try from another network to confirm.

#Layer by layer, up to the application

The ladder above answers “is my internet working?”. When the internet works but one service does not, go further up, one layer at a time, until something fails. Each layer has its own command, and each failure looks different:

Session-layer problems (a login that keeps expiring, a WebSocket that keeps reconnecting) have no network command of their own: they show up in the application logs. And always compare refused with timed out: a refusal is an answer from a live host, a timeout is silence, and they lead to completely different fixes.

curl -v alone walks most of the upper layers in one go, and tells you how far it got:

$ curl -v https://shop.example.com/
*   Trying 203.0.113.10:443...                              ← DNS worked
* Connected to shop.example.com (203.0.113.10) port 443     ← TCP handshake worked
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384     ← TLS handshake worked
*  expire date: Jan 15 23:59:59 2027 GMT
*  SSL certificate verify ok.
> GET / HTTP/2
< HTTP/2 503                                                ← the application answered, with an error

Play the scenarios to see where each fault stops the walk:

#Distance costs time: the speed of light

Ping times are not random. A large part of every round trip is simply distance, and distance has a hard floor set by physics.

• Light in a vacuum travels about 300,000 km/s. In glass fibre it is slowed by the glass to about 200,000 km/s, roughly two-thirds as fast.
• That is 5 µs per kilometre one way, or about 1 ms of round trip for every 100 km of cable.
• The minimum round trip is therefore: RTT ≥ 2 × distance ÷ 200,000 km/s.

Worked example: Dhaka to Singapore is about 2,900 km in a straight line. One way: 2,900 ÷ 200,000 = 0.0145 s ≈ 14.5 ms. Round trip: ≈ 29 ms. That is the best physics allows; real pings are about 40–60 ms because cables follow coasts and the seabed rather than straight lines, traffic passes through landing stations and exchanges, and every router adds a little queueing.

A useful rule of thumb: real RTT ≈ 1.5–2 × the straight-line minimum. If a measured RTT is far above that, look for a detour (traffic to a nearby country routed through Europe), congestion, or a slow last hop such as Wi-Fi.

Why this matters in system design:

• Round trips multiply distance. A first HTTPS visit needs about 4 round trips (DNS, TCP, TLS, request) before the first byte. From Dhaka to Virginia that is about 4 × 250 ms = 1 s of waiting; to Singapore 4 × 50 ms = 200 ms; to a CDN edge in Dhaka about 4 × 5 ms = 20 ms.
• Bandwidth does not shorten a round trip. A faster line finishes large downloads sooner, but each request–response still waits for the light to go there and back.
• So move the server, or remove round trips. Place servers in the region nearest your users, put static content on a CDN, terminate TLS at a nearby edge, reuse connections and use HTTP/3 to need fewer handshakes. Lesson 1.11 shows the same numbers inside the cloud: ~0.1–0.5 ms within a zone, ~1–2 ms across zones, tens to hundreds of ms across regions.

#Diagnostics in system design

• Do not block all ICMP. Allow at least Destination Unreachable (especially “fragmentation needed”), Time Exceeded and ICMPv6 Packet Too Big; blocking Echo is a choice, blocking the rest breaks things.
• Health checks should test the service, not ping. A load balancer that only pings a server will keep sending traffic to a machine whose application has crashed. Check an HTTP endpoint such as /health, or at least open a TCP connection.
• Measure from the user’s side. One ping from your laptop says little. Synthetic monitoring from several regions, and latency percentiles (p50, p95, p99) rather than averages, show what users really experience.
• Collect evidence before escalating. An mtr -rwc 100 report from the affected network, plus the time and both IP addresses, is what an ISP or cloud provider needs to act on a routing problem.
• Remember the return path. Traceroute shows only one direction. When a problem appears only for some users, run traceroute from both ends.
• Budget latency from geography. Before choosing a region, compute the minimum RTT to your users (distance × 2 ÷ 200,000 km/s) and multiply by the round trips a request needs. If the answer is too slow, no amount of server tuning will fix it: deploy closer or cache at the edge.
• Alert on certificates before they expire, and let every service report which layer failed (DNS error, connection refused, timeout, TLS error, HTTP status) in its logs and metrics, so the layer-by-layer walk is already done when you are paged.

#Try it yourself

# Ping: 5 requests, then a summary
ping -c 5 example.com          # Linux / macOS
ping -n 5 example.com          # Windows

# Large packets with Don't Fragment set (find the path MTU)
ping -M do -s 1472 example.com # Linux
ping -f -l 1472 example.com    # Windows

# Traceroute in its three flavours
traceroute -n example.com           # UDP probes, no reverse DNS
traceroute -I example.com           # ICMP probes
sudo traceroute -T -p 443 example.com   # TCP SYN probes to port 443
tracert -d example.com              # Windows

# Continuous per-hop statistics
mtr example.com
pathping example.com           # Windows

# The troubleshooting ladder
ip addr; ip route              # or: ipconfig
ping -c 3 192.168.1.1
ping -c 3 8.8.8.8
nslookup example.com
curl -I https://example.com

# Layer by layer, up to the application
ip link                                        # link state (Linux)
dig example.com                                # DNS through your resolver
dig @1.1.1.1 example.com                       # DNS through another resolver
nc -vz example.com 443                         # TCP port test (Linux / macOS)
Test-NetConnection example.com -Port 443       # TCP port test (Windows PowerShell)
ss -tlnp                                       # on a server: who listens on which port
openssl s_client -connect example.com:443 -servername example.com </dev/null | grep -E "subject|issuer|Verify"
curl -v https://example.com/ -o /dev/null      # DNS, TCP, TLS and HTTP in one go

Ping a few targets and compare: your router (about 1 ms), a server in Bangladesh, one in Singapore and one in Europe. You will see distance turn directly into milliseconds. Then check your numbers against physics: look up the straight-line distance, divide by 100 km per millisecond of round trip, and see how close real routing gets.

#Summary

Key takeaways

• ICMP is the network layer’s messaging protocol for errors and diagnostics. It rides inside IP, has types and codes, and no ports.
• Key types: 8/0 Echo Request/Reply (ping), 3 Destination Unreachable (codes 0 network, 1 host, 3 port, 4 fragmentation needed, 13 prohibited), 5 Redirect, 11 Time Exceeded (traceroute).
• Ping measures reachability, RTT, packet loss and, through mdev, jitter. It never measures bandwidth. The name comes from sonar; “Packet Internet Groper” is a backronym.
• A failed ping can mean ICMP is filtered or DNS failed, not that the service is down. Test the real service with curl or a TCP connection.
• Traceroute sends probes with TTL 1, 2, 3… and lists the routers that return Time Exceeded. Linux uses UDP (ports 33434+), Windows ICMP, and TCP mode gets through firewalls.
• In traceroute, a lone * * * or a spike at one hop is usually harmless; only loss or latency that persists to the destination matters. mtr and pathping give per-hop statistics over time.
• Path MTU Discovery depends on ICMP “fragmentation needed” / “packet too big”; blocking it causes hanging large transfers.
• Troubleshoot bottom up: own IP → gateway → 8.8.8.8 → DNS → the service. For one failing service, keep climbing: link → IP → gateway → DNS (dig) → port (nc, ss) → TLS (openssl s_client) → HTTP (curl -v). Refused means a live host with nothing listening; a timeout means something drops the packets.
• Light in fibre covers about 200 km per millisecond (5 µs/km one way): RTT ≥ 2 × distance ÷ 200,000 km/s, and real paths take 1.5–2 times that. Dhaka–Singapore ≈ 40–60 ms, Dhaka–US East ≥ ~200 ms. Only moving servers or caches closer, or cutting round trips, beats it.

Self-check: ICMP, ping, traceroute and troubleshooting29 questions