4.3 ICMP and Network Troubleshooting

4.3 ICMP and Network Troubleshooting

Quick Answer: The Internet Control Message Protocol (ICMP, RFC 792) is a Layer 3 protocol encapsulated inside IPv4 (Protocol 1) that provides diagnostic and error reporting services. Standard ICMP headers contain an 8-bit Type, 8-bit Code, and 16-bit Checksum. Core messages include Type 8/0 (Echo Request/Reply for ping), Type 3 (Destination Unreachable: Code 0 Net, Code 1 Host, Code 3 Port, Code 4 Fragmentation Needed for PMTUD), and Type 11 (Time Exceeded: Code 0 TTL Expired). The traceroute utility leverages incremental TTL values (1, 2, 3...) to elicit ICMP Time Exceeded responses from each transit router along the path.

While the Internet Protocol (IPv4) provides robust data delivery across networks, it is fundamentally a connectionless, best-effort protocol: IP possesses no native mechanism to report delivery failures, verify end-to-end reachability, or determine why a packet was discarded. To provide this vital feedback and diagnostic capability, the IETF developed the Internet Control Message Protocol (ICMP), standardized in RFC 792. In Nokia Service Router operations and day-to-day network engineering, ICMP serves as the foundation for foundational troubleshooting tools including ping and traceroute.

---

ICMP Header Architecture and Message Formatting

ICMP is an integral part of the IP layer. However, unlike lower-level protocols, ICMP messages are encapsulated directly inside an IPv4 datagram:

• The IPv4 header's Protocol field is set to decimal 1.
• ICMP does not utilize Layer 4 TCP or UDP transport ports.

The Standard ICMP Header

Common Echo and error formats have the following first eight bytes. The quoted triggering packet below applies to error messages, not Echo payloads:

 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Message-Specific Header Content               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|             Payload: Original IPv4 Header + 8 Bytes           |
|                      of Original Payload                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Field Definitions:

1. Type (8 bits): Defines the general classification or function of the ICMP message (e.g., Type 8 for Echo Request, Type 3 for Destination Unreachable, Type 11 for Time Exceeded).
2. Code (8 bits): Provides specific diagnostic context or sub-reasons for the designated Type. For example, within Type 3 (Destination Unreachable), Code 0 indicates Network Unreachable, while Code 3 indicates Port Unreachable.
3. Checksum (16 bits): Calculated as the 16-bit one's complement of the one's complement sum of the entire ICMP message (both the ICMP header and ICMP payload).
4. Message-Specific Header Content (32 bits): Varies depending on the Type and Code:
   • In Echo Request / Echo Reply (Types 8 and 0), this field contains a 16-bit Identifier and a 16-bit Sequence Number used by ping to correlate requests with replies.
   • In Destination Unreachable Code 4 (Fragmentation Needed), this field contains a 16-bit Next-Hop MTU value indicating the maximum packet size permitted on the bottleneck egress link.
5. ICMP Payload (Variable): When reporting an error, ICMP appends the IPv4 header of the triggering datagram and at least the first eight data bytes; implementations can quote more under applicable rules.
   • This 8-byte payload slice is critical: for TCP and UDP, the first 8 bytes contain the Source Port and Destination Port numbers, allowing the sending host's operating system to identify exactly which application socket originated the failed communication.

Fundamental Rules Governing ICMP Error Messages

To prevent cascading broadcast storms and infinite message loops, RFC 792 establishes strict restrictions:

• An ICMP error message is never generated in response to another ICMP error message (it may, however, be generated in response to an ICMP informational query like an Echo Request).
• An ICMP error message is never generated for packets addressed to an IP broadcast or multicast address.
• An ICMP error message is never generated for non-initial IP fragments.

---

Master Reference: Key ICMP Types and Codes

Understanding specific ICMP Types and Codes is heavily tested on the Nokia NRS I certification exam:

---

Path MTU Discovery (PMTUD)

In modern high-performance networks, fragmentation imposes severe CPU and buffering overhead on routers. The preferred approach is Path MTU Discovery (PMTUD), defined in RFC 1191:

+---------------+                +---------------+                +---------------+
|  Source Host  |                |   Router R1   |                |   Router R2   |
+---------------+                +---------------+                +---------------+
        |                                |                                |
        | 1. IP Packet (Size 1500, DF=1) |                                |
        |------------------------------->| (Egress Link MTU = 1400)       |
        |                                | R1 cannot fragment because DF=1|
        | 2. ICMP Type 3, Code 4         | Packet is dropped!             |
        |    Next-Hop MTU = 1400         |                                |
        |<-------------------------------|                                |
        |                                |                                |
        | 3. Resends Packet (Size 1400)  |                                |
        |------------------------------->|------------------------------->|

1. The sending host sets the Don't Fragment (DF = 1) flag on all transmitted IPv4 packets.
2. If a packet reaches an intermediate router (such as a Nokia 7750 SR) whose egress interface has an MTU smaller than the packet size, the router drops the packet.
3. The router transmits an ICMP Destination Unreachable, Code 4 (Fragmentation Needed and DF Set) message back to the sender, embedding the egress link's MTU in the ICMP header.
4. The sending host reads the Next-Hop MTU value, reduces subsequent packet or TCP segment sizes to fit the learned path MTU, and retransmits the data.

Exam Tip — PMTUD Black Holes: If an overzealous network firewall drops all ICMP traffic, the ICMP Type 3 Code 4 notification never reaches the sending host. Small packets (like TCP SYN handshakes) succeed, but as soon as full-sized data packets are transmitted, the connection hangs indefinitely. This failure mode is termed a PMTUD Black Hole.

---

Operational Mechanics of Troubleshooting Utilities

1. The ping Utility

The ping utility verifies basic end-to-end IP reachability, latency, and packet loss between two network nodes:

• Mechanism: The initiating host generates an ICMP Type 8 (Echo Request) with an arbitrary sequence number and timestamp payload. Upon arrival, the destination operating system kernel reflects the payload in an ICMP Type 0 (Echo Reply).
• Metrics Measured:
  • Round-Trip Time (RTT): Calculated by comparing the received timestamp with the system clock upon arrival (yielding minimum, average, and maximum RTT in milliseconds).
  • Packet Loss: Expressed as a percentage of sent requests that failed to elicit replies within the timeout period.
• Nokia SR OS Ping Syntax:

  *A:Router# ping 192.168.10.1 count 5 size 1000 do-not-fragment
  PING 192.168.10.1 1000 data bytes
  1008 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=1.42ms
  1008 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=1.38ms
  1008 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=1.45ms
  1008 bytes from 192.168.10.1: icmp_seq=4 ttl=64 time=1.39ms
  1008 bytes from 192.168.10.1: icmp_seq=5 ttl=64 time=1.41ms
  
  ---- 192.168.10.1 PING Statistics ----
  5 packets transmitted, 5 packets received, 0.0% packet loss
  round-trip min = 1.38ms, avg = 1.41ms, max = 1.45ms, stddev = 0.02ms
  

2. The traceroute Utility

The traceroute utility (or tracert in Microsoft Windows) maps the hop-by-hop routed path taken across intermediate routers between a source and a destination.

The TTL Manipulation Mechanism:

Because IP does not record the routers it traverses by default, traceroute cleverly exploits the Time to Live (TTL) field:

1. Probe 1 (TTL = 1): The sending host transmits a probe with TTL = 1.
   • The first router (Hop 1) receives the packet, decrements the TTL from 1 to 0, drops the packet, and transmits an ICMP Time Exceeded (Type 11, Code 0) message back to the sender.
   • The sender extracts the source IP from the ICMP packet, identifying Hop 1, and records the RTT.
2. Probe 2 (TTL = 2): The host transmits a probe with TTL = 2.
   • Hop 1 decrements TTL to 1 and forwards the packet.
   • Hop 2 receives the packet with TTL = 1, decrements it to 0, drops the packet, and returns an ICMP Time Exceeded (Type 11, Code 0) message.
   • The sender records Hop 2's IP and RTT.
3. Successive Probes (TTL = 3, 4, 5...): The host increments the TTL by 1 with each successive round of probes, mapping each router hop in sequential order.

Destination Arrival Termination:

How does traceroute know when it has reached the ultimate destination node?

• Unix / SR OS Implementation (UDP Probes): The probe packets are formatted as UDP datagrams addressed to an invalid, high-numbered port (typically 33434 to 33534). Transit routers inspect only the IP header and decrement the TTL. When the packet finally reaches the destination host, the host decapsulates the packet to Layer 4. Finding no application listening on port 33434, the destination host returns an ICMP Destination Unreachable, Port Unreachable (Type 3, Code 3) message. When the sender receives this Port Unreachable message, it knows the trace is complete.
• Windows tracert Implementation (ICMP Probes): Transmits ICMP Type 8 (Echo Requests) directly. When the destination host is reached, it returns an ICMP Type 0 (Echo Reply), terminating the trace.

Interpreting Traceroute Asterisks (* * *):

When a hop displays asterisks (* * *) instead of an IP address and latency:

1. A security firewall or Access Control List (ACL) along the path is silently dropping UDP probes or ICMP messages.
2. The transit router at that hop has ICMP rate limiting enabled on its control plane to conserve CPU cycles.
3. The reply has no working return path. Asymmetry alone is normal and does not necessarily cause failure.

---

Control Plane Protection and ICMP Security Hardening

In high-performance service provider routers like the Nokia 7750 SR, standard data-plane packet forwarding is executed directly by hardware silicon (FP4/FP5 chips). However, ICMP error generation can involve exception/control processing and is subject to platform-specific handling and rate limits.

Security Implications:

• ICMP Flood DoS Attacks: If malicious actors transmit streams of packets destined to unassigned IPs or with TTL=1, an unprotected router could exhaust CPM processor cycles generating ICMP errors, impacting control plane protocols like OSPF, IS-IS, and BGP.
• Network Reconnaissance: Attackers use ICMP sweeps to map active subnets and host topologies.

Hardening Best Practices in Nokia SR OS:

1. ICMP Rate Limiting (Token Bucket Policing): SR OS provides controls for ICMP generation and control-plane protection; inspect the actual platform settings rather than assuming unlimited responses or one universal implementation.
2. Disabling ICMP Redirects (Type 5): Attackers can forge ICMP Redirects to hijack traffic paths. SR OS enables administrators to suppress ICMP redirect generation across routed interfaces.
3. Permitting Path MTU Discovery: Security firewalls must be configured to permit ICMP Type 3, Code 4 through network boundaries, ensuring PMTUD operates seamlessly without creating black-hole TCP connections.

Primary technical reference

Specification or Nokia manual, checked October 20, 2026. Examples are teaching scenarios, not captured router execution.