Tracing the Internet — Part 1: ICMP, TTL, Ping & Tracert

When your internet connection is slow or a device isn’t responding, most people run to familiar tools like ping, tracert or ipconfig. These are basic network diagnostics tools on Windows, but they are powerful tools despite their simplicity with command line interfaces.

Before we get into using these tools, it’s essential to know some facts about Internet Control Message Protocol & Time to Live.

The Internet Control Message Protocol is one of the protocols that operates at the Network Layer of the OSI model. Its primary use being to issue out if data transmission process — between two or more devices — is getting its destination and at the right time.

If something goes wrong — like a packet can’t reach its destination, or takes too long — ICMP lets the sender know so the data can be resent.

ICMP is simply a protocol for communicating information about data, but it does not manage data itself. That’s why IMCP is the backbone of diagnostic tools like ping and tracert. For example, when you use ping, you’re actually sending ICMP Echo Requests to another device.

It plays a crucial role in error reporting, testing reachability, and measuring response time

Another thing to note, though, is when I mention ICMP operates at the network layer, this does not mean ICMP has have its own layer within OSI mode. Rather, IP works in conjunction with ICMP, ARP, RARP protocol process incoming or outgoing data.

Let’s cover the concept of TTL (Time to Live), since TTL is important for understanding tracert.

Each IP packet comes with a value called Time To Live (TTL) in IPv4 (or Hop Limit in IPv6) to ensure that these packets have a limited lifetime on the network. All IP packets come with 8 bit TTL or Hop Limit header fields which specify how many hops it can traverse on the path to their destination.

Each time the packet passes through a router (Layer 3 device), its TTL value is reduced by 1. If TTL reaches 0 before the packet arrives, the router simply discards it. This is to prevent packets from endlessly circulating in routing loops.

TTL is an 8-bit value, so the max possible TTL is 255. While it was originally intended to represent seconds, modern networks treat TTL purely as a hop counter.

Think of TTL like a ‘gas tank’ for your packet — every router it hits uses a little fuel. Once the tank is empty, the trip is over.

Default TTL and Hop Limit values vary between different operating systems, here are the defaults for a few:

- Linux kernel 2.4 (circa 2001): 255 for TCP, UDP and ICMP
- Linux kernel 4.10 (2015): 64 for TCP, UDP and ICMP
- Windows XP (2001): 128 for TCP, UDP and ICMP
- Windows 10 (2015): 128 for TCP, UDP and ICMP
- Windows Server 2008: 128 for TCP, UDP and ICMP
- Windows Server 2019 (2018): 128 for TCP, UDP and ICMP
- MacOS (2001): 64 for TCP, UDP and ICMP

Since different operating systems use different default TTL values, you can often make an educated guess about the OS of a host by looking at the TTL value in a packet it sends — especially if you have a rough idea how many hops away it is.
ping

At its core, ping is a command-line tool used to test connectivity between your computer and another device (like a server, website, or another machine on your network). It works by sending ICMP Echo Request packets to the destination and waiting for ICMP Echo Reply packets in return.

If you get a reply, it means:

• The device is reachable.
• The network connection is alive (at least at that moment).
• You get a basic idea of latency (delay in milliseconds).

If you don’t get a reply, it could mean:

• The host is down or unreachable.
• ICMP is being blocked by a firewall.
• There’s a DNS resolution issue.
• There’s a routing problem.

On window, the syntax for the ping command looks like this

ping <hostname or IP address>

For example, if you ping command google.com, the following output might look like this

Pinging google.com [142.250.190.78] with 32 bytes of data:
Reply from 142.250.190.78: bytes=32 time=20ms TTL=115
Reply from 142.250.190.78: bytes=32 time=21ms TTL=115
Reply from 142.250.190.78: bytes=32 time=19ms TTL=115
Reply from 142.250.190.78: bytes=32 time=20ms TTL=115

Ping statistics for 142.250.190.78:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 19ms, Maximum = 21ms, Average = 20ms

bytes -> the size of the packet (usually 32 bytes on Windows)
time -> How long it took to get a response (in milliseconds)
TTL -> the Time To Live remaining (helps infer the number of hops
Packet Loss -> it some pings don’t get replies, it shows up as lost packets

A failed ping isn’t always a sign of a down server. Many modern firewalls or servers block ICMP traffic for security reasons. That’s why tools like tracert can help further narrow things down.
tracert

While ping tells you if a device is reachable, it doesn’t tell you how your data gets there.
That’s where tracert (short for trace route) comes in.

According to Microsoft’s own documentation, tracert works by sending ICMP Echo packets to the destination with increasing TTL values. Each router along the way decreases that TTL by 1. When a router receives a packet with TTL = 0, it sends back an ICMP “Time Exceeded” message — which is how tracert learns what that hop was.

• The first packet starts with TTL = 1 and fails at the first hop.

• The second goes out with TTL = 2, reaches the second hop, and fails there.

• This continues until the destination is reached or the max TTL is hit.

Not all routers respond to these expired packets. Some silently drop them (which is why you might see * * * in your trace).
By default, tracert performs a DNS lookup on each IP it receives. If you don’t want that (and want faster results), use -d to skip hostname resolution.

On window, the syntax for the ping command looks like this

tracert <hostname or IP address>

If you use tracert command to google.com, it might looks like this:

Tracing route to google.com [142.250.190.78]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 11 ms 8 ms 10 ms 10.70.1.1
3 20 ms 18 ms 19 ms 74.125.50.10
…
10 25 ms 27 ms 26 ms 142.250.190.78

Trace complete.

The number at the start is the hop count — this is how many routers deep the packet is at that stage.

The three time values (e.g. 11 ms, 8 ms, 10 ms) are response times for three separate ICMP packets sent to that hop — it helps you see if there’s consistent delay or packet loss.

The IP address at the end is the router or node the packet hit at that hop.

There are cases where one of the hop might look like this:

2 * * * Request timed out.

This usually means your packet reached that hop, but the router didn’t send back an ICMP “Time Exceeded” message** in response.

Some routers (usually enterprise firewalls or ISP routers ) are configured to drop ICMP traffic. They still foward your packet to the next hop, but they ignore the TTL-expired ICMP request and don’t reply

A timeout does not necessarily mean a failure. If the trace continues after the timeout, it just means that hop didn’t respond, but your packet moves on.

However, a subsequent timeout could indicate that

a firewall blocking all outgoing ICMP replies.
a downed router.
or simply, your destination is unreachable.

Part 1 concluded.