If you’ve run the essential diagnostic program “ping”, you may have noticed as part of the output, it tells you the “TTL” for each test result. You may have wondered, what does TTL mean? Should I be concerned about it? What does TTL actually do? We will explore that question in today’s blog.
So first off, what is TTL shown in ping? First some background on why TTL was invented. Every bit of data on IP networks is sent using packets, and there are almost always one or more routers in between two computers speaking to each other on the internet. It is the router’s job to move these packets closer to their destination. However, sometimes things can go wrong, and routers can end up forwarding packets back and forth to one another forever. This is called a routing loop, and, there need to be protections in place to prevent these packets from being forever passed back and forth in the network.
Enter “TTL”, or “time to live”. TTL is a bit of data kept with every packet, indicating how many more routers, or hops, it is allowed to pass between before expiring. For every router a packet passes through, this TTL value will be decreased by 1. When the value reaches zero, the router handling that packet will drop the packet and will send a warning message back to the sender, letting them know the TTL expired.
Because the TTL to reach specific destinations can be useful for diagnosing problems, and because ping is a diagnostic tool, this is why ping provides the TTL alongside the better known data of ping times. However, TTL is really a lot more interesting when used with a related tool, traceroute.
Traceroute gives you detailed information about the path a packet takes, and the performance at each hop / router along that path. Traceroute would not exist without TTL. This is because traceroute exploits the expiration of TTL to get routers to give us information about where the packet is. With a TTL set to 1, the first router in a path will report back that the packet has expired. This expiration notice includes the IP address of the router. By measuring the time it takes to receive this notification, we can measure the time to reach the first hop. Send another carefully crafted packet with TTL of 2, and now we can get the same information for the second router / hop. This goes on with increasing TTL values until we have all of the information we need, or the packet reaches its final destination.
By default, in Windows and many other OS’s, the TTL will be 128 — that means that after a packet passes through 128 routers, if it hasn’t reached it’s final destination yet, the packet will expire and will be removed from the network. From the ping screenshot above, you can see a TTL reported of 117 reaching google.com. If the TTL started at 128, you would expect this to occur if google.com is 11 hops away from us. From the traceroute screenshot above, you can see that is exactly correct — the destination was 11 hops away from us.
Traceroute is a very useful diagnostic tool, as you can see what path a packet takes through the internet to reach it’s destination. If the path is “bad”, such as, going from Phoenix to Los Angeles before going on to Dallas, instead of going directly from Phoenix to Dallas, traceroute will help you notice this sub-optimal routing, giving you an opportunity to investigate and fix the cause of it. As well, if the network performance is very poor, traceroute can often help you determine which router or internet provider is to blame. This can be done by looking for increases in latency from one hop to another that is greatly more than expected for the physical distance between the two routers.
I hope this provides you a useful background on what TTL is, how it is used on the internet, and why it’s important for both normal internet traffic and for diagnostic purposes.
Do you love servers?
If you love servers like we do, we’d love to work together! IOFLOOD.com offers dedicated servers to people like you, and as part of that service, we optimize your OS installation to improve performance and stability. To get started today, click here to view our dedicated servers, or email us at sales[at]ioflood.com to ask for a custom quote.
Gabriel is the owner and founder of IOFLOOD.com, an unmanaged dedicated server hosting company operating since 2010. Gabriel loves all things servers, bandwidth, and computer programming and enjoys sharing his experience on these topics with readers of the IOFLOOD blog.