The specific meaning of TTL in Ping Command

The specific meaning of TTL in Ping Command

In short, TTL is the full time to live, which means the life cycle. The ping command uses the network layer protocol ICMP. Therefore, TTL refers to the lifecycle of a network layer packet (package, if you do not understand this sentence, go back and review the osi7 protocol. The first question is why we need to have the concept of a life cycle. Obviously, a package needs to go through a long path from one machine to another. Obviously, this path is not single, complicated, and may have loops. If a data packet enters a loop during transmission, it will keep repeating if it is not terminated. If many data packets are in this loop, this is a disaster for the network. Therefore, you need to set such a value in the package. After each packet passes through a node, this value is reduced by 1 and this operation is performed repeatedly, which may result in two results: the package reaches the destination when the value is positive or after a certain number of nodes, the value is reduced to 0. The former means that a normal transmission is completed, and the latter means that the package may have chosen a very long path or even a loop. This is obviously not what we expected, so when the value is 0, the network device will not pass the package, but directly discard it and send a notification to the package's source address, saying that the package is dead. In fact, the TTL value itself does not represent anything. For the user, the concern should be whether the packet has arrived at the destination rather than after several nodes. However, the TTL value can still obtain interesting information. Each operating system has different TTL values. You can modify the value by modifying the network parameters of some systems. For example, the default value of Win2000 is 128, and the value can be modified through the registry. Linux is usually defined as 64. However, in general, few people will modify the value of their machines, which gives us the opportunity to determine the operating system of a machine by pinging the echo TTL. Take two machines in our company as an example See the following command D:/Documents and Settings/HX> Ping 61.152.93.131 Pinging 61.152.93.131 with 32 bytes of data: Reply from 61.152.93.131: bytes = 32 time = 21ms TTL = 118 Reply from 61.152.93.131: bytes = 32 time = 19 Ms TTL = 118 Reply from 61.152.93.131: bytes = 32 time = 18 ms TTL = 118 Reply from 61.152.93.131: bytes = 32 time = 22 Ms TTL = 118 Ping statistics for 61.152.93.131: Packets: Sent = 4, stored ED = 4, lost = 0 (0% loss Approximate round trip times in Milli-seconds: Minimum = 18 ms, maximum = 22 Ms, average = 20 ms D:/Documents and Settings/HX> Ping 61.152.104.40 Pinging 61.152.104.40 with 32 bytes of data: Reply from 61.152.104.40: bytes = 32 time = 28 Ms TTL = 54 Reply from 61.152.104.40: bytes = 32 time = 18 ms TTL = 54 Reply from 61.152.104.40: bytes = 32 time = 18 ms TTL = 54 Reply from 61.152.104.40: bytes = 32 time = 13 Ms TTL = 54 Ping statistics for 61.152.104.40: Packets: Sent = 4, stored ED = 4, lost = 0 (0% loss Approximate round trip times in Milli-seconds: Minimum = 13 Ms, maximum = 28 Ms, average = 19 ms If the first TTL is 118, it can be basically determined that this is a Windows machine. From my machine to this machine, it passes through 10 nodes because 128-118 = 10. The second server should be Linux, for the same reason as 64-54 = 10. Some people may have some questions, such: 1. Isn't the package likely to go through many paths? Why are the TTL values of the four packages the same? This is because the path of the package is determined by some optimal selection algorithms. After the network topology is stable for a period of time, the route path of the package will also be relatively stable in a shortest path. We will not discuss how to calculate the routing algorithm. 2. For the second machine in the above example, why don't I think it is a Windows machine with 74 nodes? Because 128-74 = 54. To solve this problem, we need to introduce another good ICMP protocol tool. However, the first thing to declare is that a package goes through 74 nodes, which is a little scary. Such a path still does not need to be used. The tool to be introduced is tracert (* traceroute under nix). Let's take a look at the result of using this command on the second machine above. D:/Documents and Settings/HX> tracert 61.152.104.40 Tracing Route to 61.152.104.40 over a maximum of 30 hops 1 13 MS 16 MS 9 MS 10.120.32.1 2 9 MS 9 MS 11 MS 219.233.244.105 3 12 MS 10 MS 10 MS 219.233.238.173 4 15 MS 15 MS 17 MS 219.233.238.13 5 14 MS 19 MS 19 MS 202.96.222.73 14 MS 17 MS 13 MS 202.96.222.121 7 14 MS 15 MS 14 MS 61.152.81.86 8 15 MS 14 MS 13 MS 61.152.87.162 9 16 MS 16 MS 28 MS 61.152.99.26 10 12 MS 13 MS 18 MS 61.152.99.94 11 14 MS 18 MS 16 MS 61.152.104.40 Trace complete. From the result of this command, we can see that the route from my machine to the server is indeed 11 nodes (the 10 above seems to have forgotten the 0 error, it should be 64-54 + 1, ), instead of 128 TTL passing through more than 70 nodes. Now that we have already mentioned this, let's take a look at the two advanced ICMP commands. The ping command is used to send an ICMP request packet regardless of the default TTL value of the operating system. For example, if you still use that Linux machine, run the following command: D:/Documents and Settings/HX> Ping 61.152.104.40-I 11 Pinging 61.152.104.40 with 32 bytes of data: Reply from 61.152.104.40: bytes = 32 time = 10 ms TTL = 54 Reply from 61.152.104.40: bytes = 32 time = 13 Ms TTL = 54 Reply from 61.152.104.40: bytes = 32 time = 10 ms TTL = 54 Reply from 61.152.104.40: bytes = 32 time = 13 Ms TTL = 54 Ping statistics for 61.152.104.40: Packets: Sent = 4, stored ED = 4, lost = 0 (0% loss ), Approximate round trip times in Milli-seconds: Minimum = 10 ms, maximum = 13 Ms, average = 11 ms D:/Documents and Settings/HX> This command defines the TTL of the packet sending as 11, and we know that I have to go through 11 nodes on this server, so this output is no different from the previous one. Try again now: D:/Documents and Settings/HX> Ping 61.152.104.40-I 10 Pinging 61.152.104.40 with 32 bytes of data: Reply from 61.152.99.94: TTL expired in transit. Reply from 61.152.99.94: TTL expired in transit. Reply from 61.152.99.94: TTL expired in transit. Reply from 61.152.99.94: TTL expired in transit. Ping statistics for 61.152.104.40: Packets: Sent = 4, stored ED = 4, lost = 0 (0% loss ), Approximate round trip times in Milli-seconds: Minimum = 0 ms, maximum = 0 ms, average = 0 ms D:/Documents and Settings/HX> As you can see, the result is different. I defined the TTL as 10 to send the packet. The result is TTL expired in transit. That is to say, the lifecycle of the packet ends before it reaches the server. Note that the preceding IP address is the last IP address that we tracert returned to the server. The TTL of the packet is reduced to 0 here, as discussed above, when the TTL is reduced to 0, the device will discard the packet and send an ICMP feedback with TTL expiration to the source address. The result here is the best proof. Once again, it proves that the process from my machine to the server goes through 11 nodes instead of more than 70. Finally, I want to consolidate my knowledge. Some people may think that the tracer command is amazing and we can find the route path of a package. In fact, the principle of this command is discussed above. Imagine what would happen if I sent a packet whose TTL is 1 to the target server? According to the previous discussion, TTL will be reduced to 0 for the first node departing from Port Bao. Then, the node will respond to the feedback of TTL failure, this response contains the IP address of the device, so that we can get the address of the first node of the route path. Therefore, we continue to send a packet whose TTL is 2, and the response will be invalidated by the TTL of the second node. And so on, one by one, we find that when the final returned result is not TTL failure but ICMP response, our tracert is over, that's just that simple. By the way, the ping command also has a-n parameter that specifies the number of packets to be sent. If this number is specified, the packet will be sent according to your requirements, instead of the default four packets. If the-t parameter is used, the command will always send the packet until you forcibly stop it.

From http://www.gbunix.com/htmldata/2006_05/16/29/article_1305_1.html