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 functioning are 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 one 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 increasing 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:
Ping 192.168.1.1 –L 1024
You can see a real world example of how this command works, in Figure A.
Figure A: Appending the –L command to the ping command allows you 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 as 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.
Trace Route
Another reason why the TTL value is so useful is
because a troubleshooting tool called 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 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 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 inaction.
Figure B: The tracert command can be 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.
Figure C: You can perform 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.
No comments:
Post a Comment