Opening Framing: The Network's Error-Reporting System
Every protocol you have studied so far — Ethernet, IPv4, IPv6, ARP — moves data or
resolves addresses. None of them tells you what went wrong when something breaks. That
is the job of ICMP (Internet Control Message Protocol). ICMP is the
network's built-in error-reporting and diagnostic mechanism. When a router drops a
packet because the TTL expired, it sends an ICMP message. When a destination is
unreachable, the last reachable device sends an ICMP message. When you type
ping or traceroute, you are using ICMP.
ICMP is not a transport protocol — it does not carry application data. It rides inside IP packets (Protocol number 1 in the IPv4 header, as you learned in Week 7) and exists solely to report conditions about the network itself. Without ICMP, a network engineer would have no standard way to test reachability, discover path failures, or measure round-trip latency. Every troubleshooting workflow you will use in your career starts with the tools built on ICMP.
This week teaches you how ICMP works at the packet level, what the different types and
codes mean, how ping tests reachability, and how traceroute
uses TTL manipulation to map the path between two hosts. You will also learn why some
networks block ICMP and what operational consequences follow when they do.
Learning Outcomes
- LO1: Explain the role of ICMP within the IP protocol suite and why it exists as a separate protocol rather than being part of TCP or UDP.
- LO2: Identify the most operationally important ICMP types and codes (Echo Request/Reply, Destination Unreachable, Time Exceeded, Redirect) and describe what each one reports.
- LO3: Describe exactly how
pingworks at the packet level, including ICMP Echo Request/Reply, sequence numbers, and round-trip time calculation. - LO4: Explain how
tracerouteuses incrementing TTL values to discover each hop along a path, and interpret a traceroute output including timeouts and asymmetric paths. - LO5: Use
ping,traceroute, and Wireshark to diagnose reachability problems and identify where in the path a failure occurs.
Key insight: ping tells you whether a destination is reachable; traceroute tells you the path packets take to get there. Together they are the first two tools in every network troubleshooting workflow.
1) What ICMP Is and Where It Lives in the Stack
ICMP is defined in RFC 792 (ICMPv4) and RFC 4443 (ICMPv6). It is a Layer 3 protocol that travels inside IP packets — the IPv4 Protocol field is set to 1 for ICMPv4, and the IPv6 Next Header field is set to 58 for ICMPv6. ICMP does not use port numbers and is not a transport protocol. It is a control-plane mechanism: it reports conditions about the network, it does not carry user data.
ICMP messages are generated by routers, firewalls, and hosts in response to specific events. A router that drops a packet because the TTL reached zero generates an ICMP Time Exceeded message. A router that cannot find a route to the destination generates an ICMP Destination Unreachable message. A host that receives an ICMP Echo Request generates an ICMP Echo Reply. In every case, the ICMP message is sent back to the source IP address of the packet that triggered the event.
ICMP message encapsulation
+------------------+------------------+------------------+
| Ethernet | IPv4 Header | ICMP Message |
| Header | (Proto = 1) | (Type + Code |
| (Layer 2) | (Layer 3) | + Data) |
+------------------+------------------+------------------+
ICMP is NOT a Layer 4 protocol. It has no port numbers.
It rides directly inside IP, identified by Protocol = 1 (IPv4)
or Next Header = 58 (IPv6).
Some administrators block all ICMP traffic as a "security measure." This breaks
Path MTU Discovery (which depends on ICMP Type 3, Code 4), prevents
traceroute from working, and makes troubleshooting significantly
harder. RFC 4890 provides guidance on which ICMP types should never be blocked.
Blanket ICMP filtering is generally considered harmful to network operations.
2) ICMP Types and Codes: The Error Vocabulary
Every ICMP message contains a Type field (8 bits) that identifies the category of message, and a Code field (8 bits) that provides additional detail within that category. Together, the Type and Code tell you exactly what happened and why. The following table covers the types you will encounter most frequently in network operations and security analysis.
| Type | Code | Name | What it means | Who generates it |
|---|---|---|---|---|
| 0 | 0 | Echo Reply | Response to a ping; confirms the destination is reachable and responding | Destination host |
| 3 | 0 | Destination Unreachable — Network | No route to the destination network exists in the routing table | Router |
| 3 | 1 | Destination Unreachable — Host | The network is reachable but the specific host did not respond to ARP | Last-hop router |
| 3 | 3 | Destination Unreachable — Port | The host is reachable but no application is listening on the destination port (UDP) | Destination host |
| 3 | 4 | Fragmentation Needed (DF set) | Packet is too large for the outgoing link and the Don't Fragment bit is set | Router at the MTU bottleneck |
| 3 | 13 | Communication Administratively Prohibited | An access control list (ACL) or firewall rule blocked the packet | Filtering device |
| 5 | 0-3 | Redirect | A better next-hop gateway exists for this destination; the host should update its routing | Router |
| 8 | 0 | Echo Request | A ping request; asks the destination to confirm reachability | Source host (ping initiator) |
| 11 | 0 | Time Exceeded — TTL Expired | The packet's TTL reached zero; it was discarded | Router that decremented TTL to 0 |
| 11 | 1 | Time Exceeded — Fragment Reassembly | Not all fragments arrived within the reassembly timeout | Destination host |
ICMP message structure (first 8 bytes)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-specific data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For Echo Request/Reply:
- Type-specific data = Identifier (16 bits) + Sequence Number (16 bits)
- Followed by optional payload (often timestamps or pattern data)
For Destination Unreachable / Time Exceeded:
- Type-specific data = unused (32 bits of zeros)
- Followed by the IP header + first 8 bytes of the original packet that triggered the errorWhen a router sends an ICMP Destination Unreachable or Time Exceeded message, it includes the IP header and first 8 bytes of the payload from the packet that caused the error. This allows the source host to identify which flow or connection triggered the problem. In Wireshark, you can expand this embedded header to see the original source, destination, protocol, and port information.
3) How Ping Works: Echo Request and Echo Reply
ping is the simplest and most widely used network diagnostic tool. It
tests whether a remote host is reachable and measures the round-trip time (RTT) for
packets to travel to the destination and back. Despite its simplicity, ping reveals
critical information about connectivity, latency, and packet loss.
The Ping Process
- Source sends ICMP Echo Request (Type 8, Code 0). The ping utility constructs an ICMP Echo Request with an Identifier (to match replies to the correct ping session), a Sequence Number (incrementing with each packet), and an optional payload (often a timestamp or pattern data for MTU testing).
- Packet is forwarded through the network. The Echo Request is encapsulated in an IP packet and forwarded hop by hop using normal routing. At each router, the TTL is decremented and MAC addresses change, exactly as described in Week 7.
- Destination receives the Echo Request and generates an Echo Reply (Type 0, Code 0). The destination swaps the source and destination IP addresses, changes the ICMP Type from 8 to 0, recalculates the checksum, and sends the reply back through the network.
- Source receives the Echo Reply. The ping utility matches the reply to the original request using the Identifier and Sequence Number, calculates the round-trip time, and displays the result.
Ping output example (Windows)
C:\> ping 8.8.8.8
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=14ms TTL=118
Reply from 8.8.8.8: bytes=32 time=13ms TTL=118
Reply from 8.8.8.8: bytes=32 time=15ms TTL=118
Reply from 8.8.8.8: bytes=32 time=14ms TTL=118
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 15ms, Average = 14ms
Interpretation:
- bytes=32: payload size of each Echo Request
- time=14ms: round-trip time for that packet
- TTL=118: TTL of the reply packet (started at 128, crossed ~10 hops)
- 0% loss: all 4 packets received repliesPing output example (Linux)
$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=14.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=13.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=14.5 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=14.1 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 13.800/14.150/14.500/0.254 ms
Key differences from Windows:
- Linux sends 56 bytes of ICMP payload by default (vs. 32 on Windows)
- icmp_seq shows the sequence number
- mdev shows standard deviation of RTT (jitter indicator)What Ping Results Tell You
| Ping result | Meaning | Next diagnostic step |
|---|---|---|
| Reply received | Destination is reachable and responding; path is working in both directions | Check RTT for latency issues; note TTL for hop count estimation |
| Request timed out | No reply received within the timeout; could be packet loss, firewall, or the destination is down | Run traceroute to find where the path breaks |
| Destination host unreachable | A router or the local host generated ICMP Type 3, Code 1; the host's network is reachable but the host itself is not | Check the target host's IP, ARP table on the last-hop router, and Layer 2 connectivity |
| Destination network unreachable | A router generated ICMP Type 3, Code 0; no route to the destination network | Check routing tables along the path for missing routes |
| TTL expired in transit | A router generated ICMP Type 11; packet's TTL reached zero before arriving | Possible routing loop; run traceroute and look for repeating hops |
| Intermittent loss (some replies, some timeouts) | Congestion, flapping link, or rate-limited ICMP on a device along the path | Run extended ping (more packets) and check for patterns; examine interface error counters |
A successful ping proves Layer 3 reachability between two IP addresses. It does
not prove that a specific application port is open, that the application is healthy,
or that firewalls permit application traffic. After confirming ping works, the next
step is to test the actual service (e.g., curl, telnet to
a port, or application-specific health checks).
4) How Traceroute Works: Mapping the Path with TTL
traceroute (Linux/macOS) or tracert (Windows) discovers
every router hop between the source and destination. It works by exploiting the TTL
field in the IPv4 header — the same field you studied in Week 7. The technique is
elegant: send packets with deliberately low TTL values and let each router along the
path reveal itself by sending back an ICMP Time Exceeded message.
The Traceroute Process
- Send a packet with TTL = 1. The first router in the path decrements the TTL to 0, drops the packet, and sends back an ICMP Time Exceeded (Type 11, Code 0) message. The source IP of that ICMP message reveals the first router's address.
- Send a packet with TTL = 2. The first router decrements to 1 and forwards. The second router decrements to 0, drops, and sends back ICMP Time Exceeded. Now the source knows the second hop.
- Continue incrementing TTL. Each round reveals the next router in the path. The process continues until either the destination is reached (which responds with an ICMP Echo Reply or a Port Unreachable depending on the implementation) or the maximum hop count is exceeded.
Traceroute mechanism visualized
TTL=1 → Router A drops, sends ICMP Time Exceeded → Source learns "Hop 1 = Router A"
TTL=2 → Router A forwards → Router B drops, sends ICMP TE → Source learns "Hop 2 = Router B"
TTL=3 → A forwards → B forwards → Router C drops, sends ICMP TE → "Hop 3 = Router C"
TTL=4 → A → B → C → Destination replies → Traceroute completeTraceroute output example (Windows tracert)
C:\> tracert 8.8.8.8
Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 8 ms 7 ms 8 ms 10.220.0.1
3 12 ms 11 ms 12 ms 203.0.113.45
4 * * * Request timed out.
5 14 ms 13 ms 14 ms 72.14.237.69
6 14 ms 14 ms 13 ms 8.8.8.8
Trace complete.
Interpretation:
- Hop 1: Default gateway (1 ms — local LAN, very fast)
- Hop 2: ISP first router (8 ms — noticeable WAN latency)
- Hop 3: ISP backbone (12 ms — additional transit)
- Hop 4: * * * — this router does not respond to TTL-expired packets (ICMP filtered)
- Hop 5: Google edge router (14 ms)
- Hop 6: Destination reached (14 ms total round-trip)Windows tracert vs. Linux/macOS traceroute
| Feature | Windows tracert |
Linux/macOS traceroute |
|---|---|---|
| Probe protocol | ICMP Echo Request | UDP (default) to high-numbered ports; ICMP with -I flag |
| Destination detection | ICMP Echo Reply from destination | ICMP Port Unreachable (Type 3, Code 3) from destination (UDP mode) |
| Probes per hop | 3 | 3 (configurable with -q) |
| Max hops default | 30 | 30 (configurable with -m) |
An asterisk (*) means no ICMP Time Exceeded reply was received for
that probe within the timeout. This usually means the router at that hop is
configured to suppress ICMP TTL-exceeded messages (rate-limiting or ACL). It does
not necessarily mean the path is broken — notice that hops 5 and 6
responded normally. The packet still traversed hop 4; the router simply chose not
to generate the error message.
5) The Packet Path: Same-Subnet vs. Routed ICMP Traffic
ICMP traffic follows the same forwarding rules as any other IP traffic. This is an important point: there is nothing special about how ping or traceroute packets are routed. They use the same routing table lookups, the same ARP resolutions, and the same same-subnet versus routed delivery logic from Week 7.
Scenario 1: Pinging a host on the same subnet
Host A: 10.1.1.10/24 pings Host B: 10.1.1.20/24
1. Host A ANDs destination with mask → same subnet
2. Host A ARPs for 10.1.1.20 → gets Host B's MAC
3. ICMP Echo Request sent directly:
Ethernet: src=A_MAC, dst=B_MAC
IP: src=10.1.1.10, dst=10.1.1.20, Proto=1 (ICMP)
4. Host B replies directly to Host A (same MAC/IP swap logic)
5. No router involved — traffic stays on the local LAN segmentScenario 2: Pinging a host on a remote subnet
Host A: 10.1.1.10/24 pings Server: 10.2.2.50/24
Gateway: 10.1.1.1
1. Host A ANDs destination with mask → different subnet
2. Host A ARPs for 10.1.1.1 (gateway) → gets router's MAC
3. ICMP Echo Request:
Ethernet: src=A_MAC, dst=Router_MAC
IP: src=10.1.1.10, dst=10.2.2.50, Proto=1
4. Router receives, looks up 10.2.2.0/24 in routing table
5. Router decrements TTL, re-encapsulates with new MACs
6. Packet arrives at Server, which sends Echo Reply back
7. Reply follows the reverse path through the routerScenario 3: Traceroute to a remote host
Host A: 10.1.1.10/24 → Router R1 → Router R2 → Server: 10.3.3.50/24
TTL=1: R1 receives, TTL→0, R1 sends ICMP Time Exceeded back to 10.1.1.10
Source of ICMP = R1's interface IP (e.g., 10.1.1.1)
TTL=2: R1 forwards (TTL→1), R2 receives, TTL→0, R2 sends ICMP TE back
Source of ICMP = R2's interface IP facing the inbound direction
TTL=3: R1 forwards, R2 forwards, Server receives Echo Request
Server sends ICMP Echo Reply (or Port Unreachable) back to 10.1.1.10
Host A now knows: Hop 1 = R1, Hop 2 = R2, Hop 3 = ServerThere is no "ICMP routing" separate from IP routing. When you ping a remote host, the Echo Request is forwarded by exactly the same routing table entries and forwarding logic as a TCP or UDP packet to the same destination. The ICMP replies also follow normal routing back to the source. This means that if a route is missing in one direction, replies may not return even if the forward path works.
6) Configuration and Verification: Using ICMP Tools Effectively
The basic ping and traceroute commands have additional
options that make them more powerful diagnostic tools. Knowing these options turns a
simple reachability test into a targeted investigation.
Ping Options
Windows:
ping -n 10 8.8.8.8 Send 10 pings instead of the default 4
ping -t 8.8.8.8 Continuous ping until Ctrl+C
ping -l 1472 8.8.8.8 Set payload size (useful for MTU testing)
ping -l 1472 -f 8.8.8.8 Set payload size AND set DF bit (MTU discovery)
Linux / macOS:
ping -c 10 8.8.8.8 Send 10 pings
ping -s 1472 8.8.8.8 Set payload size
ping -M do -s 1472 8.8.8.8 Set DF bit + payload size (Linux MTU test)
Cisco IOS:
ping 10.2.2.50 Basic ping (sends 5 ICMP Echo Requests)
ping 10.2.2.50 source g0/0 Specify source interface (important when testing from routers)
ping 10.2.2.50 size 1500 Set packet size
ping 10.2.2.50 repeat 100 Send 100 pingsTraceroute Options
Windows:
tracert -d 8.8.8.8 Skip DNS resolution (faster output)
tracert -h 15 8.8.8.8 Set max hop count to 15
Linux / macOS:
traceroute -n 8.8.8.8 Skip DNS resolution
traceroute -I 8.8.8.8 Use ICMP Echo Requests instead of UDP
traceroute -m 20 8.8.8.8 Set max hops to 20
traceroute -q 1 8.8.8.8 Send 1 probe per hop instead of 3 (faster)
Cisco IOS:
traceroute 10.3.3.50
traceroute 10.3.3.50 source g0/0Wireshark Filters for ICMP Analysis
icmp All ICMPv4 traffic
icmpv6 All ICMPv6 traffic
icmp.type == 8 Echo Requests only
icmp.type == 0 Echo Replies only
icmp.type == 11 Time Exceeded only (traceroute hops)
icmp.type == 3 Destination Unreachable only
icmp.type == 3 && icmp.code == 4 Fragmentation Needed (PMTUD)
ip.ttl == 1 Packets with TTL=1 (about to trigger Time Exceeded)| Diagnostic goal | Tool and approach | What to look for |
|---|---|---|
| Basic reachability | ping <destination> |
Replies received, RTT, TTL, packet loss percentage |
| Path discovery | traceroute <destination> |
Each hop's IP, RTT per hop, timeouts |
| MTU issues | ping -f -l <size> (Windows) or ping -M do -s <size> (Linux) |
If the packet is too large, you get "Fragmentation needed" — decrease size until pings succeed |
| Intermittent loss | ping -t (Windows) or ping -c 100 |
Loss percentage, RTT spikes, pattern of failures |
| Source-specific routing | ping <dest> source <interface> (Cisco) |
Whether traffic from a specific interface can reach the destination (tests asymmetric routing) |
7) Troubleshooting and Failure Modes
ICMP-based tools are the first step in every troubleshooting workflow, but interpreting their results requires understanding what each failure pattern actually indicates. The table below covers the most common failure scenarios and the reasoning path to isolate the root cause.
| Symptom | Likely cause | First diagnostic step |
|---|---|---|
| Ping to gateway succeeds but ping to internet fails | Gateway has no route to the destination, or upstream device is blocking traffic | Traceroute to the destination; identify where the path stops |
| Ping fails with "Destination host unreachable" from your own gateway | The gateway cannot ARP for the destination on its directly connected network | Check whether the destination host is on the correct VLAN and subnet; verify ARP on the gateway |
| Traceroute shows the same two hops repeating in a loop | Routing loop between two routers; packets bounce back and forth until TTL expires | Check routing tables on both routers for conflicting or default routes pointing at each other |
| Ping works but traceroute shows * * * for every hop | ICMP Time Exceeded (TTL expired) messages are being filtered, but Echo Replies are allowed | This is a filtering policy, not a path failure; the path works (ping proves it) |
| Ping with large packet size fails but small pings work | MTU bottleneck in the path; DF bit is set and the packet is too large | Decrease the payload size until pings succeed; the working size reveals the path MTU |
| Ping to remote host works from Router A but not from Host behind Router A | Return route is missing — the remote side can reach the router's interface but not the host's subnet | Check the remote router's routing table for a route back to the host's subnet |
| High latency on first ping, normal on subsequent pings | First ping triggered an ARP resolution (or NDP in IPv6), adding delay | Normal behavior; the ARP cache was empty and had to be populated. Not a fault. |
Systematic Troubleshooting Workflow Using ICMP
- Ping yourself (loopback):
ping 127.0.0.1. If this fails, the TCP/IP stack on your host is broken. - Ping your own IP address: Confirms the NIC is functioning and your IP is configured.
- Ping the default gateway: Tests Layer 2 connectivity to the router and Layer 3 addressing on your subnet.
- Ping a remote host by IP: Tests end-to-end Layer 3 reachability through the routing infrastructure.
- Ping a remote host by name: Tests DNS resolution in addition to network connectivity.
- Traceroute to the remote host: If ping failed, traceroute identifies where in the path the failure occurs.
Some organizations block all inbound ICMP as a security hardening measure. While this prevents ICMP-based reconnaissance (ping sweeps, OS fingerprinting via TTL), it also breaks Path MTU Discovery, prevents legitimate troubleshooting, and can cause mysterious application failures (especially with VPNs and tunnels that depend on ICMP Fragmentation Needed messages). Best practice is selective filtering: block ICMP Redirects (Type 5) and limit Echo Request rates, but allow Destination Unreachable (Type 3) and Time Exceeded (Type 11) to preserve operational visibility.
Real-World Design Context: ICMP in Operations and Security
ICMP is not just a lab tool. It powers monitoring systems, enables critical protocol mechanisms, and surfaces in security analysis across every enterprise network.
- Network monitoring systems: Tools like Nagios, PRTG, Zabbix, and cloud-native health checks (AWS NLB, Azure Load Balancer) use ICMP Echo to monitor host availability. When a ping check fails, the monitoring system generates an alert. Blocking ICMP on monitored hosts creates blind spots in operational visibility.
- Path MTU Discovery: As covered in Week 7, PMTUD relies on ICMP Type 3, Code 4 (Fragmentation Needed). If this message is blocked by a firewall, TCP connections may hang when sending large packets over paths with smaller MTUs. This is the "black hole" problem — packets are silently dropped with no error reaching the sender.
-
Security reconnaissance: Attackers use ICMP for network discovery.
A ping sweep (
fping,nmap -sn) identifies live hosts. TTL values in Echo Replies help fingerprint operating systems (Linux default 64, Windows 128, network devices 255). Traceroute reveals network topology and firewall placement. Defenders must balance the need for operational ICMP with the exposure these tools create. - ICMP tunneling: Because ICMP payloads can carry arbitrary data, attackers have used ICMP Echo Request/Reply as a covert communication channel (ICMP tunneling). Unusual ICMP payload sizes or frequencies in packet captures may indicate data exfiltration. This is covered in NET202 (Network Security).
- SLA measurement: Service providers use continuous ping and traceroute measurements to track latency, jitter, and packet loss against SLA (Service Level Agreement) commitments. The RTT and loss statistics from ICMP are often the contractual basis for performance guarantees.
Guided Lab: Tracing Packet Paths and Analyzing ICMP Error Codes
Goal: Use ping, traceroute, and Wireshark
to observe ICMP message types in real traffic, trace a path across multiple hops, and
diagnose a simulated failure.
Prerequisites
- Wireshark installed (or Packet Tracer with simulation mode)
- A network connection with at least one router between you and the target
- Terminal or command prompt access
Part A: Observing Ping in Wireshark
- Start a Wireshark capture on your active interface with the filter:
icmp - Run:
ping -c 4 8.8.8.8(Linux) orping -n 4 8.8.8.8(Windows) - Stop the capture. You should see 4 Echo Requests (Type 8) and 4 Echo Replies (Type 0).
- For one Echo Request, expand the ICMP section and record:
- Type and Code values
- Identifier and Sequence Number
- Payload size
- For the corresponding Echo Reply, confirm:
- Same Identifier and Sequence Number
- Type changed from 8 to 0
- Source and Destination IP addresses are swapped
Part B: Observing Traceroute in Wireshark
- Start a new capture with filter:
icmp - Run:
tracert -d 8.8.8.8(Windows) ortraceroute -I -n 8.8.8.8(Linux with ICMP mode) - Stop the capture after traceroute completes.
- Identify the packets with TTL = 1, TTL = 2, TTL = 3, etc. (expand the IP header for each).
- For each TTL value, find the corresponding ICMP Time Exceeded reply (Type 11, Code 0).
- Record which router IP generated each Time Exceeded message and compare to the traceroute output.
- Find the final Echo Reply from the destination — note the TTL change compared to the Echo Requests.
Part C: Generating and Observing an Error
- With Wireshark capturing, ping an IP address you know does not exist on your local subnet (e.g.,
ping 10.1.1.254if no device uses that address). - Observe the result. You should see either:
- ARP requests with no reply (if the address is on your subnet but no host responds), or
- ICMP Destination Unreachable from your gateway (if the address is on a remote network with no route)
- Record the ICMP Type and Code, and explain which device generated the error and why.
Deliverable
A report containing: (1) annotated Wireshark screenshots of an Echo Request/Reply pair with Identifier, Sequence Number, and Type/Code labeled, (2) a traceroute output alongside the matching ICMP Time Exceeded packets from Wireshark showing the TTL progression, and (3) a captured ICMP error message with your explanation of what triggered it and which device generated it.
Week 9 Outcome Check
By the end of this week, you should be able to:
- Explain what ICMP is, where it lives in the protocol stack, and why it uses Protocol number 1
- Identify the most important ICMP types and codes and explain what each one reports
- Describe exactly how ping works at the packet level, including Echo Request/Reply matching via Identifier and Sequence Number
- Explain how traceroute uses incrementing TTL values to map each hop along a path
- Interpret traceroute output including timeouts (* * *), asymmetric paths, and routing loops
- Use the systematic ping workflow (loopback, own IP, gateway, remote by IP, remote by name) to isolate failures
- Capture and read ICMP messages in Wireshark to confirm what you observe in ping and traceroute output
Next week covers Infrastructure Services: DHCP and DNS — how hosts automatically receive IP configurations and how domain names resolve to addresses.
Hands-On Labs
Use these activities to build practical skills with ICMP tools and packet analysis.
Lab 1: Ping Interpretation Drill
Task: Ping 5 different targets (local host, gateway, a public DNS server, a known-unreachable IP, and a hostname). For each, record the result, RTT, TTL, and the ICMP type/code observed. Classify each result as: reachable, unreachable (network), unreachable (host), timeout, or DNS failure.
Deliverable: A table of 5 ping results with classification and explanation.
Why it matters: Distinguishing between different ping failure modes is the foundation of every troubleshooting workflow.
Time estimate: 20-25 minutes
Lab 2: Traceroute Comparison
Task: Run traceroute to three different destinations (e.g., 8.8.8.8, 1.1.1.1, and a server in a different geographic region). Compare the hop counts, latency per hop, and whether any hops show * * * timeouts. Explain any differences in path length or latency.
Deliverable: Three traceroute outputs with annotations explaining the path differences.
Why it matters: Understanding that different destinations take different paths through the internet is foundational for network engineering.
Time estimate: 25-35 minutes
Lab 3: MTU Discovery Using Ping
Task: Using ping with the DF (Don't Fragment) flag and varying payload sizes, discover the Path MTU between your host and a remote target. Start at 1500 bytes and decrease in steps of 100 until pings succeed, then narrow down in steps of 10. Record the largest payload that succeeds without fragmentation.
Deliverable: A log of payload sizes tested, which succeeded and which failed, and the calculated Path MTU (payload size + 20 bytes IP header + 8 bytes ICMP header).
Why it matters: MTU mismatches cause silent failures in VPNs, tunnels, and WAN links. Knowing how to discover the path MTU is a critical operational skill.
Time estimate: 20-30 minutes
Lab 4: ICMP in Packet Tracer Simulation
Task: Build a 3-router linear topology in Packet Tracer. Configure IP addresses and static routes. Use simulation mode to trace a ping from one end to the other, observing each hop's forwarding decision. Then remove one static route and observe the ICMP Destination Unreachable message generated.
Deliverable: Screenshots of the simulation showing the packet at each hop, and a screenshot of the ICMP error when the route is missing.
Why it matters: Seeing ICMP messages generated in real time by simulated routers builds intuition for how errors propagate in real networks.
Time estimate: 35-45 minutes
Checkpoint Questions
- What Protocol number identifies ICMP in the IPv4 header? Why is ICMP not considered a transport-layer protocol?
- A ping to
10.2.2.50returns "Destination host unreachable" from IP10.2.2.1. What does this tell you about where the failure is? What ICMP Type and Code does this message use? - Explain the difference between "Request timed out" and "Destination network unreachable" as ping results. Which one means a router could not find a route?
- How does traceroute use the TTL field to discover each router along a path? What ICMP message does each intermediate router generate?
- In a traceroute output, hop 4 shows
* * *but hops 5 and 6 respond normally. Is the path broken at hop 4? Explain. - Why does the first ping to a new destination often have a higher RTT than subsequent pings?
- What is the operational risk of blocking all ICMP traffic on a firewall? Name two specific mechanisms that break.
- You can ping a remote server by IP address but not by hostname. The IP ping returns replies. What layer is the problem at, and what should you check?
Weekly Reflection
Reflection prompt (200-300 words):
This week gave you the first real troubleshooting tools in the networking toolkit. Reflect on how ping and traceroute fit into the broader troubleshooting methodology.
- Why is a systematic approach (loopback → own IP → gateway → remote) more effective than randomly pinging targets?
- How does understanding ICMP types and codes change what you can learn from a simple ping failure?
- When would traceroute be more useful than ping? When would ping be sufficient on its own?
- What are the trade-offs of filtering ICMP in a security-conscious enterprise? How would you advise a security team that wants to block all ICMP?
A strong reflection should connect the diagnostic techniques from this week to the forwarding and addressing concepts from Weeks 4-8.
Recommended References
- RFC 792: Internet Control Message Protocol (ICMPv4) — the original ICMP specification defining all message types, codes, and behaviors.
- RFC 4443: ICMPv6 for the Internet Protocol Version 6 — the IPv6 equivalent, covering Neighbor Solicitation/Advertisement and other ICMPv6-specific messages.
- RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls — guidance on which ICMP types should be permitted through firewalls to preserve operational functionality.
- RFC 1191: Path MTU Discovery — explains how ICMP Fragmentation Needed messages enable hosts to discover the maximum MTU along a path.
- Cisco Networking Academy: Networking Basics — ICMP, ping, and traceroute modules aligned with CCNA Day 11 objectives.
- Wireshark ICMP Analysis: Wireshark User Guide — reference for ICMP display filters and protocol dissection.
- SANS SEC503: Intrusion Detection In-Depth — Day 2 covers ICMP analysis in a security monitoring context, including ICMP tunneling detection and reconnaissance patterns.
Read RFC 792 sections 1-4 alongside your Wireshark captures. Matching the specification's Type/Code definitions to live packets builds the deepest understanding of what each ICMP message means.
Week 09 Quiz
Test your understanding of ICMP types and codes, ping mechanics, traceroute TTL behavior, and ICMP-based troubleshooting.
Take Week 09 Quiz