Free lesson · Computer Networking

Basic ping

Easy11 min readnetworkingcomputer-networkstcp-ip

The Diagnostic Protocol of the Internet

When something goes wrong on a network - a server is unreachable, a route is broken, a packet is too large to forward - the network needs a way to communicate error information back to the sender. IP itself has no error-reporting mechanism. It is a best-effort delivery protocol that silently drops packets when problems occur. Without a companion protocol, every failure would be invisible - the sender would simply never receive a response and have no idea why.

ICMP (Internet Control Message Protocol) fills this gap. It is a network-layer protocol used by routers and hosts to send error messages and diagnostic information. ICMP is not a transport protocol like TCP or UDP - you do not send application data over ICMP. It is a control protocol that keeps the network operational by reporting problems and enabling diagnostic tools.

ICMP is defined in RFC 792 for IPv4 and RFC 4443 for IPv6 (where it is called ICMPv6). It is the protocol behind two of the most important network diagnostic tools: ping (tests connectivity) and traceroute (maps the path packets take through the network). Every network engineer, system administrator, and infrastructure-aware software engineer uses these tools regularly.

ICMP Message Types

ICMP messages are categorized by a type number and a code number within each type. The most important types for software engineers:

Destination Unreachable (Type 3) - Codes

The Destination Unreachable type has multiple codes that specify exactly why the packet could not be delivered:

The "Port Unreachable" code (3) is particularly useful for debugging. When you send a UDP packet to a port where no application is listening, the receiving host sends back an ICMP Port Unreachable message. This is how your system knows a UDP service is not running - unlike TCP, where you would get a RST (reset) packet.

The "Fragmentation Needed" code (4) is critical for Path MTU Discovery. When a router cannot forward a packet because it exceeds the next link's MTU and the Don't Fragment flag is set, it sends this ICMP message back to the sender with the maximum MTU of the next link. The sender then reduces its packet size accordingly. This is the standard mechanism for discovering the MTU along the entire path without actually fragmenting packets.

Ping - Testing Connectivity

ping is the simplest and most frequently used network diagnostic tool. It sends ICMP Echo Request messages to a target and listens for Echo Reply messages. If the target is reachable and responding, you get replies with round-trip time measurements. If not, you get timeout or error messages that indicate the nature of the problem.

# Basic ping
ping google.com

# Output:
# PING google.com (142.250.80.46): 56 data bytes
# 64 bytes from 142.250.80.46: icmp_seq=0 ttl=116 time=12.3 ms
# 64 bytes from 142.250.80.46: icmp_seq=1 ttl=116 time=11.8 ms
# 64 bytes from 142.250.80.46: icmp_seq=2 ttl=116 time=12.1 ms

# Ping with count limit (5 pings then stop)
ping -c 5 google.com

# Ping with specific packet size
ping -s 1400 google.com

Reading Ping Output

Each line of ping output tells you several things:

• 64 bytes: The size of the response (56 bytes of data + 8 bytes of ICMP header)
• from 142.250.80.46: The IP address that responded (confirms the destination is reachable)
• icmp_seq=0: The sequence number (increments with each ping, helps identify lost pings)
• ttl=116: The Time To Live remaining when the response arrived (the initial TTL was likely 128, meaning the packet crossed ~12 routers)
• time=12.3 ms: The round-trip time - how long the Echo Request took to reach the destination and the Echo Reply took to come back

After stopping ping (Ctrl+C), you get a summary:

# --- google.com ping statistics ---
# 3 packets transmitted, 3 received, 0% packet loss, time 2003ms
# rtt min/avg/max/mdev = 11.8/12.1/12.3/0.2 ms

This summary shows packet loss percentage (0% means perfect connectivity, any loss indicates a problem) and round-trip time statistics (minimum, average, maximum, and standard deviation). The standard deviation indicates jitter - high jitter means inconsistent latency.

What Ping Failures Mean

Warning: Many servers and firewalls block ICMP traffic for security reasons. A ping failure does not always mean the host is down - it might mean ICMP is being filtered. AWS security groups, for example, do not allow ICMP by default. You must explicitly add an inbound rule for ICMP to enable ping. Before concluding a host is unreachable, verify whether ICMP is allowed by the firewall configuration.

Traceroute - Mapping the Network Path

While ping tells you whether a destination is reachable and how long the round trip takes, traceroute shows you every router (hop) between you and the destination. It is invaluable for diagnosing where in the network a problem occurs - is the issue at your ISP, at an internet exchange, at the destination's network, or at the destination server itself?

How Traceroute Works

Traceroute exploits the TTL (Time To Live) field in the IP header. Each router that forwards a packet decrements the TTL by 1. When TTL reaches 0, the router drops the packet and sends an ICMP Time Exceeded message back to the sender. Traceroute uses this behavior systematically:

1. Send a packet with TTL=1. The first router decrements it to 0 and sends back a Time Exceeded message. You now know the first hop.
2. Send a packet with TTL=2. The first router decrements to 1 and forwards. The second router decrements to 0 and sends Time Exceeded. You now know the second hop.
3. Continue incrementing TTL until the packet reaches the destination, which responds with an Echo Reply (or a Port Unreachable for UDP-based traceroute).

# macOS / Linux
traceroute google.com

# Output:
# traceroute to google.com (142.250.80.46), 30 hops max
#  1  192.168.1.1 (192.168.1.1)  1.2 ms  0.9 ms  1.1 ms
#  2  10.0.0.1 (10.0.0.1)  8.3 ms  7.9 ms  8.1 ms
#  3  72.14.215.85 (72.14.215.85)  10.2 ms  9.8 ms  10.5 ms
#  4  108.170.252.1 (108.170.252.1)  11.4 ms  11.2 ms  11.6 ms
#  5  142.250.80.46 (142.250.80.46)  12.3 ms  12.1 ms  12.5 ms

# Windows
tracert google.com

graph LR
    subgraph Traceroute["Traceroute: TTL-Based Path Discovery"]
        direction LR
        SRC["Source"] -->|"TTL=1"| R1["Hop 1<br/>192.168.1.1<br/>1.2 ms"]
        R1 -->|"TTL=2"| R2["Hop 2<br/>10.0.0.1<br/>8.3 ms"]
        R2 -->|"TTL=3"| R3["Hop 3<br/>72.14.215.85<br/>10.2 ms"]
        R3 -->|"TTL=4"| R4["Hop 4<br/>108.170.252.1<br/>11.4 ms"]
        R4 -->|"TTL=5"| DST["Destination<br/>142.250.80.46<br/>12.3 ms"]
    end

    style SRC fill:#4f46e5,stroke:#4338ca,color:#fff
    style R1 fill:#7c3aed,stroke:#6d28d9,color:#fff
    style R2 fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style R3 fill:#a78bfa,stroke:#8b5cf6,color:#fff
    style R4 fill:#c4b5fd,stroke:#a78bfa,color:#000
    style DST fill:#22c55e,stroke:#16a34a,color:#fff

This diagram shows how traceroute discovers each hop along the path. The source sends packets with incrementing TTL values. With TTL equals 1, the first hop router at 192.168.1.1 responds in 1.2 milliseconds. With TTL equals 2, the second hop at 10.0.0.1 responds in 8.3 milliseconds. With TTL equals 3, the third hop at 72.14.215.85 responds in 10.2 milliseconds. With TTL equals 4, the fourth hop at 108.170.252.1 responds in 11.4 milliseconds. With TTL equals 5, the packet reaches the destination at 142.250.80.46 in 12.3 milliseconds.

Reading Traceroute Output

Each line shows three round-trip time measurements (traceroute sends three probes per TTL value by default). Asterisks (* * *) indicate a hop that did not respond - either the router does not send ICMP Time Exceeded messages, or a firewall is blocking them. This does not necessarily mean the route is broken - the packet may still be forwarded, just without an ICMP response.

A large jump in latency between two consecutive hops often indicates a long-distance link - for example, a jump from 15 ms to 85 ms might indicate an undersea cable crossing between continents. Consistent high latency from a specific hop onward suggests congestion or a slow link at that point.

Other ICMP-Based Tools

MTR (My Traceroute): Combines ping and traceroute into a single continuously updating display. It shows every hop, with real-time statistics for packet loss and latency at each hop. MTR is superior to traceroute for diagnosing intermittent network issues because it runs continuously rather than taking a single snapshot.

Path MTU Discovery (PMTUD): Uses ICMP Fragmentation Needed (Type 3, Code 4) messages to discover the maximum packet size that can traverse the path without fragmentation. The sender starts with the local MTU and reduces it whenever a router sends back a Fragmentation Needed message. This ensures optimal packet sizes without the overhead of fragmentation.

Practical ICMP Debugging Workflow

graph TD
    subgraph Debug["Systematic Network Debugging"]
        direction TB
        S1["Step 1: Ping loopback<br/>127.0.0.1"] -->|"Fails"| F1["Local TCP/IP stack<br/>is broken"]
        S1 -->|"Works"| S2["Step 2: Ping gateway<br/>(e.g., 192.168.1.1)"]
        S2 -->|"Fails"| F2["Local network issue<br/>(cable, Wi-Fi, config)"]
        S2 -->|"Works"| S3["Step 3: Ping external IP<br/>(e.g., 8.8.8.8)"]
        S3 -->|"Fails"| F3["Routing / ISP issue<br/>or firewall blocking"]
        S3 -->|"Works"| S4["Step 4: Ping hostname<br/>(e.g., google.com)"]
        S4 -->|"Fails"| F4["DNS resolution<br/>problem"]
        S4 -->|"Works"| S5["Step 5: Traceroute<br/>to destination"]
    end

    style S1 fill:#4f46e5,stroke:#4338ca,color:#fff
    style S2 fill:#7c3aed,stroke:#6d28d9,color:#fff
    style S3 fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style S4 fill:#a78bfa,stroke:#8b5cf6,color:#fff
    style S5 fill:#22c55e,stroke:#16a34a,color:#fff
    style F1 fill:#ef4444,stroke:#dc2626,color:#fff
    style F2 fill:#ef4444,stroke:#dc2626,color:#fff
    style F3 fill:#ef4444,stroke:#dc2626,color:#fff
    style F4 fill:#ef4444,stroke:#dc2626,color:#fff

This flowchart shows the systematic network debugging workflow. Step 1: ping the loopback address 127.0.0.1 - if this fails, the local TCP/IP stack is broken. Step 2: ping the default gateway - if this fails, the problem is between your machine and the local network. Step 3: ping an external IP like 8.8.8.8 - if this fails, the issue is routing, ISP, or firewall. Step 4: ping by hostname - if this fails, DNS resolution is the problem. Step 5: use traceroute to identify exactly which hop is causing issues.

When a network connectivity issue arises, experienced engineers follow a systematic diagnostic process using ICMP tools:

Step 1 - Ping the loopback address (ping 127.0.0.1 or ping ::1). If this fails, the TCP/IP stack on the local machine is broken - the problem is not the network, it is the local system's networking configuration.

Step 2 - Ping the default gateway (your router). If the loopback works but the gateway fails, the problem is between your machine and the local network - a cable issue, Wi-Fi disconnection, or incorrect IP configuration on your interface.

Step 3 - Ping a known external IP (like 8.8.8.8, Google's public DNS). If the gateway works but external IPs fail, the problem is in the routing beyond your local network - an ISP issue, a firewall blocking outbound traffic, or a misconfigured route.

Step 4 - Ping by hostname (like ping google.com). If external IPs work but hostname resolution fails, the problem is DNS - your DNS server is unreachable, misconfigured, or returning incorrect results.

Step 5 - Traceroute to the destination. If ping to the destination fails (or shows high latency), traceroute reveals which hop is causing the problem. This narrows the issue to a specific network segment, which is critical information when escalating to the responsible team.

This systematic narrowing from local to remote, from Layer 3 to Layer 7, is one of the most valuable troubleshooting skills a software engineer can develop. It transforms "the application does not work" into a precise diagnosis like "router at hop 4 in the us-east-1 availability zone is dropping packets" - which is actionable.

ICMP and Security

ICMP is a double-edged tool. It provides essential diagnostic capabilities, but it can also be abused:

ICMP flood (ping flood): An attacker sends a massive volume of Echo Request packets to overwhelm a target's network bandwidth or processing capacity. Modern firewalls rate-limit ICMP to mitigate this.

Smurf attack: An attacker sends Echo Request packets to a network's broadcast address with a spoofed source address (the victim's address). Every device on the network responds to the victim, amplifying the attack traffic. Smurf attacks are largely eliminated by modern routers that do not forward directed broadcasts.

ICMP tunneling: Embedding data payloads inside ICMP Echo Request/Reply packets to bypass firewalls that allow ICMP but block other protocols. This is a covert channel technique used by some malware and exfiltration tools.

Because of these risks, many organizations restrict or filter ICMP traffic. Cloud providers like AWS block ICMP by default in security groups. This is a reasonable security posture, but it means that ping and traceroute may not work unless ICMP is explicitly allowed - which often leads to confusion when engineers try to debug connectivity and mistakenly conclude a host is unreachable because ping fails.

Interview: ICMP tools are the first line of debugging in any network troubleshooting discussion:

"A service in us-east-1 cannot reach a service in eu-west-1. How would you debug?" - Start with ping to test basic connectivity. If ping fails, check security groups for ICMP rules. Use traceroute to identify where the path breaks. Check if the issue is routing (no route between VPCs), firewall (security group or NACL blocking traffic), or application (service not listening on the expected port).

"Latency between two services spiked from 5ms to 200ms. What happened?" - Use traceroute or MTR to identify which hop introduced the latency. A new hop that was not present before suggests a routing change. High latency at a specific hop suggests congestion or a link degradation at that point.

"Why does ping work but my application cannot connect?" - Ping uses ICMP, which operates at Layer 3. Your application uses TCP or UDP at Layer 4. A firewall can allow ICMP (letting ping succeed) while blocking TCP on the application's port (causing the application to fail). Always test with the actual protocol your application uses, not just ping.

Module Summary

This module covered the Network Layer fundamentals that every software engineer needs. You now understand IP addressing (both IPv4 and IPv6), subnetting and CIDR notation, NAT and its implications for application design, DHCP for automatic configuration, and ICMP for network diagnostics. These concepts are the foundation for everything that follows - routing, TCP, DNS, HTTP, and the infrastructure topics that build on them.

Exercise: Starter: Ping three different servers: ping -c 5 google.com, ping -c 5 amazon.com, ping -c 5 github.com. Compare the round-trip times. Which is fastest? Can you explain why based on geographic distance or CDN placement? Now try pinging 127.0.0.1 - what is the round-trip time, and why is it so low?

Intermediate: Run traceroute google.com (or tracert on Windows). Count the number of hops. Can you identify which hops belong to your local network, which to your ISP, and which to Google's network? Look for hostnames that contain city names or ISP identifiers. If any hops show * * *, research why that hop might not respond to ICMP.

Advanced: Install MTR (brew install mtr on Mac, apt install mtr on Linux) and run mtr google.com. Watch the real-time display for 60 seconds. Does any hop show consistent packet loss? Does any hop show higher latency than expected? Use MTR to compare the path to a nearby server versus a distant server - how do the hop counts and latency profiles differ? Research how to read MTR output correctly (hint: packet loss at intermediate hops is not always a problem - loss only at the final destination is what matters).

Back to Computer Networking