skip to content

Traceroute can send UDP, ICMP Echo or TCP SYN probes; how does each mode recognise the destination, and why choose one over another?

level: middleimportance: should knowfreq 32%

answer

  1. routers answer every mode alike
  2. only the final reply differs
  3. closed port, echo reply, handshake reply
  4. what the destination's filter lets in

basics

~20 s

In all three modes routers answer an expiring probe with ICMP Time Exceeded; only the ending differs: port unreachable for UDP, Echo Reply for Echo, SYN-ACK or RST for TCP SYN. Choose the probe the destination's filters admit.

solid answer

~50 s

The probe type changes almost nothing along the path: whichever IPv4 packet a router expires, it returns ICMP Time Exceeded, type 11 code 0, and an ICMP Echo Request is a query rather than an error, so it draws Time Exceeded too. The difference is at the destination. A **UDP** probe goes to an unlikely high port and draws Destination Unreachable, type 3 code 3 (port unreachable). An **ICMP Echo** probe (type 8) draws an Echo Reply (type 0). A **TCP SYN** to a chosen port draws a SYN-ACK if something listens or an RST if not. The choice is about filters: a firewall in front of a server often drops unsolicited UDP and Echo, so those traces end in silence, while a SYN to the port the service actually uses passes the same rules as real traffic and reaches the end.

go deeper

for a junior

Recall that routers answer every probe type with Time Exceeded, and that the destination is spotted by its different reply: port unreachable, Echo Reply, or a TCP SYN-ACK or RST.

for a middle

Explain why each end reply happens: UDP's port unreachable rule, echo being a query rather than an error, TCP's response to a SYN, and how the quoted 8 bytes let each mode match replies.

for a senior

Pick the probe from the symptom: a trace ending in silence at the edge calls for a TCP SYN to the served port, and load-balanced paths may differ by probe protocol and ports.

for a principal

Frame probe choice as a measurement-validity question: which probe reproduces the path and filtering real traffic sees, and how to state what a finished or unfinished trace does and does not prove.

## What stays the same in every mode Traceroute discovers routers by sending packets with a deliberately small IPv4 **Time to Live** (`TTL`) and listening for the **ICMP Time Exceeded, type 11, code 0** that RFC 1812 obliges a router to send when it discards a packet whose TTL reached zero. That rule does not depend on what the packet carries, so the *middle* of a trace works the same whether the probe is UDP, ICMP or TCP. One detail is worth checking: ICMP errors are never sent about other ICMP **error** messages (RFC 1122 §3.2.2). An **Echo Request** is not an error; it is a query, so a router that expires one does send Time Exceeded. That is why Echo-based traces work at all. Matching works the same way too. The Time Exceeded quotes the probe's IP header and at least its first 8 payload bytes (RFC 792). In those 8 bytes sit the UDP ports, the ICMP Echo identifier and sequence number, or the TCP ports and sequence number, so each mode has somewhere to make every probe unique. ## How each mode recognises the destination The destination does not drop the probe — RFC 1122 says a host must not discard a datagram just because its TTL is below 2 — so it handles the probe like any other packet. Each mode is built to provoke a recognisable answer: | Probe | What the destination returns | Rule behind it | |---|---|---| | UDP to an unused high port | ICMP **Destination Unreachable, type 3, code 3 (port unreachable)** | RFC 1122: UDP SHOULD send port unreachable when no socket listens on the port | | ICMP **Echo Request**, type 8 | ICMP **Echo Reply**, type 0 | RFC 792 echo; RFC 1122 requires hosts to answer echo | | TCP **SYN** to a chosen port | **SYN-ACK** if listening, **RST** if closed | the TCP specification, RFC 9293 | For the UDP mode, the traditional starting port 33434 is a convention of the original tool, not a protocol rule; the only requirement is that nothing listens there, because an open port would simply accept the datagram and send no reply. For the TCP mode, either answer proves the probe arrived. A tool that received a SYN-ACK does not intend to open a connection, and implementations tear down the half-open state rather than complete it. ## Why the choice matters: filters near the destination Routers in the middle of the path rarely care what the probe is. The edge in front of the destination often does: - **Unsolicited UDP to high ports** is commonly dropped by a server-side firewall. The UDP trace then shows every router up to the firewall and asterisks after it, and never sees the port unreachable. - **ICMP Echo** is frequently filtered or rate-limited, either inbound or on the replies, for the same reason. - **A TCP SYN to the service's real port** — say, 443 for an HTTPS server — has to be allowed, or the service would not work. That probe crosses the same stateless and stateful rules as the users' traffic, so it is the mode most likely to finish. The flip side: a TCP probe that ends in a SYN-ACK can mean the reply came from a middlebox that answers on the server's behalf (some load balancers and proxies terminate TCP), so "reached the destination" means reached *whatever answers for that address and port*. Other differences an interviewer may probe: 1. **Which path is measured.** Routers that spread traffic across equal-cost paths often hash on fields including the protocol and ports, so a TCP-443 trace can follow the same path as real HTTPS traffic while a UDP trace follows another. 2. **Privileges.** Crafting ICMP or raw TCP probes usually needs raw-socket access on the sending host; plain UDP probes need only the ability to set the TTL, which RFC 1122 requires a stack to offer applications. 3. **End-host rate limits.** A destination may limit how many port unreachables or Echo Replies it emits, so the last line of a UDP or Echo trace can show partial answers even when nothing is wrong. ## Choosing in practice | Goal | Better probe | |---|---| | Classic default, no special privileges | UDP | | Destination known to answer Echo | ICMP Echo | | Trace stops in silence at a firewall | TCP SYN to the service's port | | Follow the path real application traffic takes | the application's own protocol and port | The routers' answers are identical in all three modes; what you are choosing is which **final reply** you can get, and which filters and load-balancing decisions your probes will meet on the way. In IPv6 the same three modes exist, with ICMPv6 equivalents: Time Exceeded is ICMPv6 type 3, port unreachable is Destination Unreachable type 1 code 4, and Echo uses types 128 and 129.

  • Why does a router send ICMP Time Exceeded for an expiring Echo Request, when ICMP errors are never sent about ICMP messages?
    The rule in RFC 1122 is narrower: no ICMP error about an ICMP error message. An Echo Request is an informational query, not an error, so a router that discards it on TTL expiry sends Time Exceeded like for any other packet. That is what makes Echo-based traceroute possible.
  • A UDP traceroute shows routers up to hop 9 and only asterisks after it, but a TCP SYN trace to port 443 reaches the server at hop 11. What does that suggest?
    Hops 10 and 11 forward traffic, since the TCP probes crossed them. Most likely a filter near the destination drops unsolicited UDP to high ports, or the replies to it, so neither those routers' answers nor the closing port unreachable return. Some edge routers also answer only for traffic the filter admits.

saying these in an interview costs you the question

  • Routers only send Time Exceeded for UDP probes, so ICMP traceroute cannot work
  • A TCP traceroute completes a full three-way handshake with each router
  • UDP traceroute ends when the destination sends Time Exceeded code 0
  • Port 33434 is a reserved traceroute port defined by the ICMP RFCs
  • The probe mode changes which routers answer with Time Exceeded
  • A SYN-ACK at the end always proves the real server itself was reached