54
network. But it is also an extremely poor way to test a connection. One problem is that the software stack you use to test the connection is designed to hide
problems from users. If a packet is lost, the stack will transparently have the lost packet resent without any indication to the user. You could have a connection that is losing 90 of
its packets. The problem would be immediately obvious when using ping. But with most applications, this would show up only as a slow response. Other problems include locally
cached information or the presence of proxy servers on the network.
Unfortunately, web browsers seem to be the program of choice for testing a connection. This, of course, is the worst possible choice. The webs slow response is an accepted fact of
life. What technician is going to blame a slow connection on his shoddy wiring when the alternative is to blame the slow connection on the Web? What technician would even
consider the possibility that a slow web response is caused by a cable being too close to a fluorescent light?
The only thing testing with an application will really tell you is whether a connection is totally down. If you want to know more than that, you will have to do real testing.
3.4 Microsoft Windows
The various versions of Windows include implementations of ping. With the Microsoft implementation, there are a number of superficial differences in syntax and somewhat less
functionality. Basically, however, it works pretty much as you might expect. The default is to send four packets, as shown in the two following examples. In the first, we successfully ping the host
www.cabletron.com:
C:\ping www.cabletron.com Pinging www.cabletron.com [204.164.189.90] with 32 bytes of data:
Reply from 204.164.189.90: bytes=32 time=100ms TTL=239 Reply from 204.164.189.90: bytes=32 time=100ms TTL=239
Reply from 204.164.189.90: bytes=32 time=110ms TTL=239 Reply from 204.164.189.90: bytes=32 time=90ms TTL=239
C:\
In the next example, we are unable to reach www.microsoft.com for reasons previously explained:
C:\ping www.microsoft.com Pinging microsoft.com [207.46.130.149] with 32 bytes of data:
Request timed out. Request timed out.
Request timed out. Request timed out.
Note that this is run in a DOS window. If you use ping without an argument, you will get a description of the basic syntax and a listing of the various options:
55
C:\ping Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
[-r count] [-s count] [[-j host-list] | [-k host-list]] [-w timeout] destination-list
Options: -t Ping the specifed host until interrupted.
-a Resolve addresses to hostnames. -n count Number of echo requests to send.
-l size Send buffer size. -f Set Dont Fragment flag in packet.
-i TTL Time To Live. -v TOS Type Of Service.
-r count Record route for count hops. -s count Timestamp for count hops.
-j host-list Loose source route along host-list. -k host-list Strict source route along host-list.
-w timeout Timeout in milliseconds to wait for each reply.
Notice that the flooding options, fortunately, are absent and that the -t option is used to get an output similar to that used in most of our examples. The implementation does not provide a summary at the
end, however.
In addition to Microsofts implementation of ping, numerous other versions—as well as more generic tools or toolkits that include a ping-like utility—are available. Most are free or modestly priced.
Examples include tjping, trayping, and winping, but many more are available, including some interesting variations. For example, trayping monitors a connection in the background. It displays a
small heart in the system tray as long as the connection is up. As availability changes frequently, if you need another version of ping, search the Web.
56
Chapter 4. Path Characteristics
In the last chapter, we attempted to answer a fundamental question, Do we have a working network connection? We used tools such as ping to verify basic connectivity. But simple connectivity is not
enough for many purposes. For example, an ISP can provide connectivity but not meet your needs or expectations. If your ISP is not providing the level of service you think it should, you will need
something to base your complaints on. Or, if the performance of your local network isnt adequate, you will want to determine where the bottlenecks are located before you start implementing expensive
upgrades. In this chapter, we will try to answer the question, Is our connection performing reasonably?
We will begin by looking at ways to determine which links or individual connections compose a path. This discussion focuses on the tool traceroute. Next, we will turn to several tools that allow us to
identify those links along a path that might cause problems. Once we have identified individual links of interest, we will examine some simple ways to further characterize the performance of those links,
including estimating the bandwidth of a connection and measuring the available throughput.
4.1 Path Discovery with traceroute
This section describes traceroute, a tool used to discover the links along a path. While this is the first step in investigating a paths behavior and performance, it is useful for other tasks as well. In the
previous discussion of ping, it was suggested that you work your way, hop by hop, toward a device you cant reach to discover the point of failure. This assumes that you know the path.
Path discovery is also an essential step in diagnosing routing problems. While you may fully understand the structure of your network and know what path you want your packets to take through
your network, knowing the path your packets actually take is essential information and may come as a surprise.
Once packets leave your network, you have almost no control over the path they actually take to their destination. You may know very little about the structure of adjacent networks. Path discovery can
provide a way to discover who their ISP is, how your ISP is connected to the world, and other information such as peering arrangements. traceroute is the tool of choice for collecting this kind of
information.
The traceroute program was written by Van Jacobson and others. It is based on a clever use of the Time-To-Live TTL field in the IP packets header. The TTL field, described briefly in the last chapter,
is used to limit the life of a packet. When a router fails or is misconfigured, a routing loop or circular path may result. The TTL field prevents packets from remaining on a network indefinitely should such
a routing loop occur. A packets TTL field is decremented each time the packet crosses a router on its way through a network. When its value reaches 0, the packet is discarded rather than forwarded. When
discarded, an ICMP TIME_EXCEEDED message is sent back to the packets source to inform the source that the packet was discarded. By manipulating the TTL field of the original packet, the
program traceroute uses information from these ICMP messages to discover paths through a network.
traceroute sends a series of UDP packets with the destination address of the device you want a path to.
[1]
By default, traceroute sends sets of three packets to discover each hop. traceroute sets the TTL
