-I option in the traceroute command forces the use of ICMP Echo Requests instead of UDP packets. This is critical when a Netfilter firewall drops or rate-limits standard UDP probes, allowing administrators to verify network paths that would otherwise appear broken due to packet filtering policies.
The Default Behavior and UDP Limitations
By default, most implementations of traceroute on Linux systems utilize User Datagram Protocol (UDP) packets sent to high port numbers (typically starting at 33434). The utility relies on receiving "Time Exceeded" messages from intermediate routers and an "Port Unreachable" message from the destination host to map the route. However, this method is fragile in environments with strict firewall rules.
Netfilter, the packet filtering framework integrated into the Linux kernel, often treats these UDP probes as noise or potential attacks. Many enterprise firewalls are configured to drop incoming UDP traffic on ephemeral ports to prevent UDP-based denial-of-service attacks or simply because the application does not require such connectivity. When a firewall drops these initial probes, traceroute cannot receive the necessary ICMP error messages, resulting in timeouts (* * *) for every hop. This creates a false negative where the path appears down, even though the underlying IP connectivity is intact. Understanding why UDP fails is the first step toward using alternative protocols like ICMP.
How the -I Option Changes Packet Structure
The -I flag instructs traceroute to send Internet Control Message Protocol (ICMP) Echo Request packets instead of UDP datagrams. These are the same packets used by the ping utility. By switching to ICMP, you bypass the specific UDP filtering rules that were blocking your previous attempts. Intermediate routers process ICMP packets differently than UDP packets regarding their handling of TTL (Time To Live) expiration. When a router receives an ICMP Echo Request with a TTL of 1, it decrements the TTL to 0, discards the packet, and sends back an ICMP Time Exceeded message to the source. This mechanism allows traceroute to identify the hop without relying on UDP-specific error handling.
This approach is particularly useful when troubleshooting connectivity issues between hosts where ICMP is permitted but UDP is restricted. It provides a clearer picture of the routing path because it aligns with the most fundamental layer of IP diagnostics. If you can successfully ping a host, using traceroute -I will likely yield a complete trace, assuming no intermediate devices are dropping ICMP Echo Requests specifically.
Firewall Configuration and Netfilter Rules
When dealing with Netfilter, administrators must ensure that the firewall rules allow the necessary ICMP traffic. While many firewalls drop UDP aggressively, they may still permit ICMP Echo Requests for basic diagnostics. However, some security-hardened systems drop all ICMP types or implement rate-limiting on Echo Requests. If you encounter partial traces where the first few hops succeed but later hops timeout, the issue might be an intermediate firewall dropping ICMP rather than the final destination. In such cases, checking the Netfilter logs on the gateway can reveal if DROP or REJECT actions are being applied to icmp-echo-request packets.
It is also important to note that some modern firewalls treat ICMP Echo Requests similarly to UDP floods if not properly rate-limited. Therefore, while -I solves the protocol mismatch issue, it does not guarantee success if the network infrastructure actively blocks ICMP entirely. Administrators should verify their iptables or nftables rules to ensure that ACCEPT policies exist for ICMP traffic in both INPUT and FORWARD chains. For example, a rule allowing icmp type echo-request is often sufficient for traceroute -I to function correctly across trusted networks.
Practical Implementation and Diagnostics
To execute a trace using ICMP, simply append the -I flag to your command: traceroute -I target_hostname. This command will initiate a series of ICMP Echo Requests with incrementing TTL values. If the trace succeeds, you will see a list of IP addresses corresponding to each hop, along with round-trip times. If it fails, compare the output with a standard ping test. A successful ping combined with a failed traceroute -I suggests that intermediate routers are dropping ICMP Time Exceeded messages, which is common in some cloud providers or managed services that obscure their internal topology.
In contrast, if traceroute (UDP) fails but traceroute -I succeeds, the evidence points directly to UDP blocking. This distinction helps network engineers narrow down whether the issue lies with application-layer firewalls, stateful inspection modules, or simple ACLs. Additionally, consider using mtr with the --icmp flag as an alternative, as it provides continuous monitoring and can confirm if the ICMP path remains stable over time. This dual-protocol verification strategy ensures that network visibility is not compromised by arbitrary firewall policies.
Frequently Asked Questions
Why does traceroute show asterisks with UDP but work with -I?
Asterisks indicate that no response was received within the timeout period. UDP probes are often dropped by firewalls that do not expect traffic on high ephemeral ports, whereas ICMP Echo Requests are frequently allowed for basic diagnostics. Switching to -I bypasses these UDP-specific restrictions.
Can I use traceroute -I if ping is blocked?
No. Since traceroute -I uses ICMP Echo Requests, it requires the same permissions as ping. If a firewall blocks ICMP Echo Requests, both commands will fail to receive responses, resulting in timeouts for all hops.
Does the -I option work on Windows tracert?
The Windows tracert command uses ICMP by default, so it behaves similarly to traceroute -I on Linux. However, Linux traceroute defaults to UDP, making the -I flag essential for matching Windows behavior or bypassing UDP filters.
What if traceroute -I works but shows very high latency?
High latency may indicate that ICMP packets are being rate-limited by the firewall or that the route is traversing congested links. Check if intermediate devices are prioritizing other traffic types or applying quality-of-service (QoS) policies that delay ICMP processing.
Is there a risk of triggering intrusion detection systems with -I?
While less risky than UDP scans, rapid ICMP probing can still trigger IDS/IPS alerts if the volume is high. Use the -w flag to increase wait times between probes, reducing the likelihood of appearing as a scanning attack.