To troubleshoot Windows network connectivity problems, use this introduction to time-to-live (TTL) and trace route (tracert) ping commands to learn how to detect packet loss that would slow performance, causing network latency or lost connections.
This tip originally appeared on WindowsNetworking.com.
So far in this article series, I have shown you all kinds of tricks that involve using the ping command to diagnose network connectivity problems. In this article, I want to continue the discussion by showing you some variations of these techniques.
Packet loss
So far when we have used the ping command, the command has either been successful, or it has failed. There really has not been any in-between. As you may recall, the ping command is designed to return four different responses. Occasionally, one or more of these responses may fail while others succeed. When this happens, it means that packet loss is occurring.
In such a situation, the local host and the remote host or both are functioning properly, but conditions exist that cause some packets to be lost along the way. The TCP/IP protocol is designed so that it can retry the transmission when packet loss occurs, but packet loss kills performance. A slow connection with no packet loss will often outperform a high-speed connection on which packet loss is occurring.
The tricky thing about packet loss is that it can sometimes be hard to spot. Sure, you know that packet loss is occurring if some of the ping responses fail, but ICMP packets used by pinging are so small that they will often be successfully returned even if a network condition exists that may cause packet loss in real world situations.
If you suspect that packet loss may be occurring but ping is not returning any errors then you can try i...
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
ncreasing the size of the ICMP packets. Larger packets are more prone to failure if network problems exist. You can tell ping to use larger packet sizes by using the –L switch.
Using the –L switch is simple. All you have to do is enter the ping command followed by the address that you want to ping, and the –L switch and the number of bytes that you want to send. For example, suppose that your network was experiencing poor performance when connecting to a particular host. You suspect that packet loss is occurring, but ping is consistently successful. Therefore, you decide to tell ping to use a packet size of 1024 bytes. To do so, you would use the following command:
You can see a real world example of how this command works, in Figure A:
[IMAGE]
Figure A: Appending the –L command to the ping command to increase the size of the ICMP packet
Time-to-live
The next concept that I want to discuss in relation to the ping command is that of time-to-live (TTL). If you take a look at Figure A, you will notice that each of the ping replies ends in TTL=64.
As you probably know, the Internet consists of a huge number of routers that are connected to each other. Every router is connected to at least two other routers. The idea behind this architecture is that if a link fails, there should be at least one other path to the destination. The problem with this type of architecture is that under certain circumstances link failures could cause packets to travel in circles for infinity, never actually reaching their destination.
This is where the TTL value comes into play. Think of the TTL value as a self-destruct mechanism for the packet. The TTL value is initially set at a fairly high number, although this number varies depending on the operating system that is being used. Every time the packet travels across to a router, the packet is said to have performed a hop. Each time that a hop occurs, the TTL value is decremented by one. If the TTL value reaches zero, the packet is destroyed. This keeps a lost packet from traveling around the Internet for all eternity.
Traceroute
Another reason why the TTL value is so useful is because a troubleshooting tool called traceroute (tracert) is based on it. Using the ping command is fine for troubleshooting small networks in which the remote host is in close proximity to the sending host, but when it comes to the Internet or to a wide area network (WAN) the remote host may be thousands of miles away. As such, the ICMP packet generated by the ping command may have to travel through dozens of routers in order to reach the remote host. You may occasionally run into situations in which the local host and the remote host or both are working correctly, but one of the routers somewhere along the way is having problems. Fortunately, you can use the tracert command to diagnose these types of problems.
The tracert command is actually based on the ping command. The basic idea behind tracert is that it sends out an ICMP packet to the remote host, but with the TTL value set to one. This causes the first router encountered to send back a TTL expired in transit message. This message contains information that identifies the router that produced the message. The router's identification is documented, and then the ICMP packet is sent out again, but this time with a TTL value of two. This time, the ICMP packet reaches the second router before the TTL value expires. This process is repeated, increasing the TTL value by one each time, until the host is eventually reached. This allows you to see a report of all of the routers between the local host and the remote host. You can sometimes use this information to spot problems along the route that may be affecting traffic flow.
Using the tracert command is very similar to using the ping command. To do so, simply enter the tracert command followed by the IP address or the fully qualified domain name of the remote host. Figure B shows the tracert command in action:
[IMAGE]
Figure B: Tracert command being used to spot problems with traffic flow
There are a couple of different things to keep in mind when using the tracert command. First, some hosts use a firewall to block ICMP packets. As such, you will sometimes see a series of asterisks indicating that trace route was not able to get information from a particular host.
Another thing to keep in mind is that, like the hosts themselves, every router is assigned an IP address. Regardless of whether they are used for hosts or for routers, IP addresses are structured in a way that allows them to reflect their geographic location. In fact, sometimes this geographic information or even a description of the router is provided within the tracert. If you want more information though, there are third-party tools that can graphically track the tracert command based on this geographic information. You can see an example of such a tool in Figure C:
[IMAGE]
Figure C: Performing a visual tracert to determine a host's geographic location
Conclusion
In this article, I have shown you how to increase the number of bytes used by the ping command in an effort to make it easier to spot packet loss. I then went on to introduce you to the tracert command. In the next part of this article series, I will continue the discussion by showing you how to interpret the results provided by tracert.
About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
[IMAGE]
WindowsNetworking.com contains a wealth of networking information for administrators: Featuring information on how to setup and troubleshoot various networks of any size. Also includes a comprehensive archive of hundreds of reviewed networking software and hardware solutions. Frequently updated with articles and tips by a team of leading authors, it remains a favorite within the networking community.
