By Jason Levitt
November 18, 1996

The Internet Zone takes you into the hidden world of yo ur Internet connection to answer the question:

Where do my packets go and why is performance so lame?

Network debugging is not for amateurs. It's a cruel, thankless game that can turn spirited individuals into emotional cripples. But as a business user of intranets or the Internet, you're part of the game whether you like it or not. Your network connection probably goes down from time to time, and it almost certainly goes down, or gets mighty slow, right when you're in the middle of a deadline. Here at the Internet Zone, We'd like to help you become a player rather than a whiner, and when it comes to network connections, the Internet Zone has one slogan: Know thine enemy.

This week's column helps you look at your TCP/IP network connection using some of the same readily available tools that your friendly network engineer uses. The goal is to help you understand your network connections a bit better and maybe even communicate diagnostic informat ion to whomever debugs your network. When you're through with this Internet Zone visit you'll probably still be cursing your Internet connection, but you may also be able to yell sophisticated stuff at your IT support group like, "I'm losing 20% of my packets!" or "It's taking me 450 milliseconds to reach the ISP!"

First, You'll Need Some Tools:
We'll use two handy tools-called ping and traceroute-to investigate your Internet connection. These tools have been part of various Unix systems for at least a decade and now are available for other platforms. You can find versions for your favorite operating system here. See table below Ping and traceroute are frequently used by network administrators to debug network connections on TCP/IP networks, but they are also generally useful for gathering simple performance information about network connections. We'll use them to get a better idea about where your network packets are going and how lon g it's taking them to reach their destination.

Fortunately, ping and traceroute are easy to use and understand. Ping sends a message to a host that you designate and waits for a reply. When ping receives the reply, it tells you how long it had to wait, in milliseconds. Traceroute does essentially the same thing but it sends a message to every node along the route between you and the designated host. When each host replies, traceroute displays that host's name and how long it took to respond. Traceroute is an easy way to get a closer look at where your network connections lie. By using traceroute, you can sometimes determine what machine is slowing your Internet connection down. Traceroute may also show you various errors that occur during packet transmission, such as unreachable hosts or dropped packets.

Disclaimer: I'd like to point out that my description of traceroute and ping is somewhat simplistic. For a quick technical description of exactly what traceroute and ping do (using acronyms like ICMP, TTL and UDP), check out Kevin Dowd's book, Getting Connected: The Internet At 56K And Up, p. 172.

Where To Find Ping And Traceroute Software

Operating System	Ping	Traceroute
Windows 95 or Windows NT	Try the command ping from a DOS command prompt or download Luc Neijens' WhoIs utility	Try the command tracert from a DOS command prompt or download Luc Neijens' WhoIs utility
Windows 3.1 or MS-DOS	Ask your TCP/IP stack vendor	Ask your TCP/IP stack vendor
Unix systems	Try the command ping from a shell command line prompt	Try the command traceroute from a shell command line prompt
Macintosh (Open Transport)	WhatRoute 1.3.1	WhatRoute 1.3.1
Macintosh (MacTCP)	MacTCP Watcher 2.0	MacTraceroute 1.1

Looking At Your Connection:
Once you have the tools, you can take a look at an Internet connection. Peter Davis, New Business Developmen t product engineer at UUNET Technologies, has generously offered to explain the output of ping and traceroute tools, and to provide general guidance.

To investigate our Internet connection, which was located at UUNET's booth on the show floor of the Microsoft Site Builder's Conference held last month in San Jose, Calif., we pointed our TCP/IP-connected Macintosh at three well-known Web sites: http://www.yahoo.com, http://www.pipex.net, and http://www.microsoft.com. We used the WhatRoute utility running on a Macintosh Powerbook 5300CE. Also, in the final example below, we used a telenet program to login to a Unix shell account at UUNET's site in Fairfax, Va., where we used the Unix traceroute command running on a DEC PC running BSDI's BSD/OS.

We started with http://www.yahoo.com. Here's the output of traceroute using the Macintosh WhatRoute utility:

Peter: Geographically, http://www.yahoo.com is very close to us, so you'd think it would be fast and we'd get there in a very short number of hops, but that may or may not be the case. It depends on how their service provider built their network.

Jason: Can you give us a brief summary of the output fields above?

Peter: First column is the number of hops navigated. The second column is the host name of the hop. The number in parentheses is the IP address of the hop. The last three columns are the time in milliseconds (ms) from your machine to the host listed on that line. Three attempts are made to contact the host and therefore there are three times listed. Three attempts gives us a better sample than just one attempt, although 50 attempts would give us a better idea of how well the connection responds.

Jason: Some lines list an IP address instead of a host name.

Peter: Usually those are routers, but they could be machines that a service provider has decided not t o name.

Jason: What does the asterisk mean?

Peter: Usually that means no response was received, but in this case it probably means we've encountered a router that does not allow or support traceroute. We can route through it, but we can't get any information about it, so the traceroute command puts an asterisk there instead of a host name.

Jason: When we finally reached our destination, it says http://www1.yahoo.com, but we had entered http://www.yahoo.com. What happened?

Peter: When we entered the destination host name, www.yahoo.com, the utility converted that host name into an IP address using the local DNS server. The utility uses IP addresses to "discover" the next hop, but then uses DNS again to resolve the IP address back into a host name. In this case, Yahoo is running a server farm and the actual machine name in the server farm was http://www1.yahoo.com.

Jason: When I look at the numbers, it seems that it took longer to get to some intermedi ate nodes than it took to get to the destination. Why is that?

Peter: Since networks are sometimes busy and sometimes not, you'll find that 50 ms or 100 ms differences are common.

Jason: So, how do I read the traceroute output to get an idea of how good my connection is?

Peter: Often, it's packet loss that causes delays. We can use the ping utility to ping some of the routers repeatedly to find out if there is packet loss to a particular hop. So here we ping nw.sc.psi.net 32 times:

Peter: We're looking for consistently poor performance, which we'd see in the average round trip time, in this case 55 ms. 55 ms isn't too bad at all, since we are directly connected via a T1 line. Also, any packet loss above 10% would be an indicator of problems. Some people would argue that even 5% is unacceptable. Above, we see that packet loss is 0% which means we didn't lose any packets.

Jason: H mmm. Connectivity to Yahoo looks pretty good then.

Peter: Yup.

Jason: Let's try traceroute to the overseas site.... http://www.pipex.net.

Peter: That site is in the UK. The missing times (asterisk are printed instead) probably indicates dropped packets. Let's follow-up the trace by pinging the site:

Peter: That 15.6% packet loss very likely due to the lack of bandwidth and infrastructure in overseas connections. It's a known problem that, although the availability of network infrastructure and capacity on each continent is pretty high, the amount of capacity available between continents is poor and very expensive. By the way, telephone dial-up users will typically experience up to 10% packet loss simply because of the poor quality of the connection between modems over analog phone lines. Let's look at one last conne ction. First, we'll telnet to an account at UUNET in Fairfax, Va., and then try a traceroute, from the Unix command line, to Microsoft:

Peter: It looks like the circuit may be down inside of Microsoft since our traceroute hangs right after the Microsoft gateway machine. I went ahead and killed that traceroute because it was taking so long.

Conclusions:
Jason: Peter, can the average user debug a network connection?

Peter: Not really, It's a relatively complex task to debug network connections, mostly because it takes quite a bit of probing and back-end knowledge to say who's responsible for a network problem. The best a typical user can do is to merely say there's a problem. However, there are three basic strategies for probing a TCP/IP network connection that may provide interesting results:

• Use ping to see the average round trip time and percentage packet loss. A packet loss greater than 10% definitely shows you have a poor connection.
  
• Do a traceroute to see what hosts are between your machine and the destination and then ping each host in the route to see what kind of response you get. What constitutes a bad ping time depends on the type of Internet connection you have and whether you try to connect domestically or overseas. If you are connected via a T1 or better, and your route is domestic, good performance is generally under 30 ms. Expect an analog phone line to be significantly higher.
  
• Use traceroute to see how many network service providers you're going through to get to your destination. You can usually determine the network provider by looking at the host name. PSI=psi.net, CERF=cerf.net, UUNET=alter.net, ISI=isi.net. Going through more than three providers means your connection probably won't be very fast. Note that our initial traceroute to http://www.yahoo.com showed that we went through three providers, PSI, CERF, and ISI.

Jason: Thanks, Peter!

Return to AuthorITies or view AuthorITies archives

Comments?

http://www.informationweek.com

---

---