In an IPv4 traceroute, why can a middle hop show only asterisks while later hops answer, and why might the trace never reach the destination?

## What an asterisk actually means A traceroute prints an asterisk for a probe when **no matching reply arrived before the timeout**. It does not say which way the problem lies. For one probe there are two packets that could go missing: 1. the **probe** itself, on its way out with a small `TTL`; 2. the **reply** — ICMP **Time Exceeded, type 11, code 0** from a router, or the destination's final answer — on its way back. And there is a third possibility: no reply was ever generated. Separating these three is the whole skill. ## A silent hop with answering hops after it The decisive observation is that **later hops answer**. A probe with TTL 8 that draws a Time Exceeded from hop 8 must have crossed hop 7. So hop 7 forwards traffic; what it does not do is return Time Exceeded to you. The protocol rules leave room for that: - **Origination switched off.** RFC 1812 §5.2.7.3 says a router MUST send Time Exceeded code 0 when it discards a packet for an expired TTL, but it **MAY** have a per-interface option to disable originating these messages, provided the option **defaults to on**. An operator may have turned it off. - **Rate limiting.** RFC 1812 §4.3.2.8 says a router SHOULD be able to limit the rate at which it sends ICMP errors, Time Exceeded included, and leaves the method to the implementer. A hop showing one asterisk out of three is often this. For IPv6, RFC 4443 goes further: a node MUST rate-limit the ICMPv6 errors it originates, and it warns that limiters which cannot cope with bursts such as traceroute's are not recommended. - **A source address that cannot come home.** RFC 1812 §4.3.2.4 makes the router source the message from an address of the interface the message leaves through. If that interface is numbered from private RFC 1918 space, a filter on the return path that drops packets from such sources, or the lack of a route back for them, silently discards the reply. - **Return-path filtering.** The Time Exceeded travels back by whatever route the network chooses, which may differ from the forward path, and a firewall there — including one at your own edge — may drop inbound ICMP. None of these affects the traffic you care about, and that is the point an interviewer wants: **a silent intermediate hop followed by answering hops is not evidence of a fault at that hop.** ## A trace that never reaches the destination The other pattern is asterisks from some hop all the way to the tool's maximum hop count (an implementation setting, commonly 30). Here the question is what happens at the end of the path. The tool waits for the destination's distinctive reply — a **port unreachable (type 3, code 3)** for UDP probes, an **Echo Reply (type 0)** for Echo probes, a **SYN-ACK or RST** for TCP SYN probes — and something stops it: | Cause | What the trace shows | |---|---| | A firewall in front of the destination drops unsolicited UDP to high ports | routers answer up to the firewall, then asterisks to the hop limit | | The destination or its edge drops ICMP Echo, or its replies | the same, for an Echo-based trace | | The destination rate-limits port unreachables or Echo Replies | the final line shows some replies and some asterisks | | The last routers are reached, but filters drop their Time Exceeded | silence that may hide a path that actually works | | A real fault: no route onward, or a link down | silence, or a Destination Unreachable from a router | Because the first four look like the fifth, the next step is to **change the probe** before concluding anything. A TCP SYN to the port the service really uses must be admitted by the destination's filters for the service to work at all, so it is the probe most likely to finish. If it does, the path is fine and the earlier trace was measuring filtering policy. ## A different pattern: the same addresses repeating Not every incomplete trace is silent. If hops alternate between the same two or three addresses until the hop limit, the probes are circling a **routing loop**. Every router in the loop keeps expiring higher-TTL probes and returning Time Exceeded code 0 — exactly the condition RFC 1122 says code 0 indicates: "a gateway routing loop or too small an initial TTL value." That is a genuine forwarding fault, and it shows up as noise, not silence. ## How to reason about it in an interview - An asterisk is **a missing reply**, not by itself proof that data packets are dropped. - A silent hop with **answering hops after it** forwards fine; the cause sits in ICMP origination, rate limiting or the reply's return path. - A trace that **stops** may be measuring a filter's policy toward the probe type; change the probe type before blaming the path. - **Repeating addresses** mean a loop, which is a real fault. Interpreting per-hop loss and latency statistics over time is a diagnostic-tooling subject of its own; the protocol view above explains why the replies are there or not.