Internet Access Problems Troubleshooting Balky Web Sites News & Views Feature Article

by Whitney Quesenbery, Vice President Cognetics Corporation Originally published in News & Views September, 1997 issue. Copyright 1997 STC-Philadelphia Metro Chapter. For permission to reprint this article, contact the Managing Editor.

Most of us have been frustrated by not being able to get to a Web site. Maybe it was there one day and gone the next. Or someone tells you about a site, but when you try to see it, all you get is a frozen browser and the cryptic message, "Contacting host." What’s going on here? Is the ’Net about to break down from too many people using it? The answer is, "Well, sort of." There is no instant solution, but there are some tools that can help you figure out what’s going on. First a little technical background (with apologies to technical purists). The Internet is held together by routers. These special computers are the traffic cops of the ’Net, directing the traffic of information packets from one machine to another until they reach their destination. A router only talks to other routers, and they can only say three things: Yes, you can send that packet towards its destination through me. No, you can’t get there through me. No, I can’t get you there, but that router over there can. And, all traffic on the ’Net from a URL to email to file transfer to a Web page is broken down into these packets. So, let’s look at what happens when you ask for a URL. Every Internet host has access to a Domain Name Server which maintains the list of all of the known public addresses. Before your request is ever sent out over the ’Net, your browser looks up the address in the DNS. If the address you are looking for is not on the list, you’ll see a message like "Host Unknown." Without this first piece of information, your host computer does not know where to send the message. Where is your DNS server? In Windows 95, the IP address for the DNS server you use is stored in the TCP/IP properties (on the DNS Configuration tab) of your network settings. See Figure 1. Figure 1. DNS Address So what do you do when you’re sure you have a correct address, but still can’t seem to get to the site? The first step is to try to "ping" the site. Like the submarine sonar the name is borrowed from, Ping sends out a short message (usually three times) and waits for a reply. A version of Ping is included with Windows 95. It is run from the DOS prompt. The file should be in your \windows\ directory, which should be on your path. If you installed another Internet access package, Ping was probably included with it. For other systems, you may have to look for the correct location and include path information in the command line. To ping the PMC web site, go to a DOS prompt and type: C:\WINDOWS>ping stc.org Notice that you ping a server, not a specific Web page. You should see something like the results shown in Figure 2. Pinging stc.org [204.31.201.1] with 32 bytes of data: Reply from 204.31.201.1: bytes=32 time=144ms TTL=241 Reply from 204.31.201.1: bytes=32 time=181ms TTL=241 Reply from 204.31.201.1: bytes=32 time=154ms TTL=241 Figure 2. Results from Ping There is one line of reply message for each "ping." (Most ping programs send out three or four pings at a time.) The most important thing this tells you is that your computer can find the domain host you are looking for, so you know that that site is "up" and in communication with the rest of the ’Net. The detail in the reply lines tells us that the stc.org site (also known by its IP address of 204.32.201.1) sent back all 32 bytes of data in times ranging from 144 ms to 181 ms. Any time under 200 ms is good, but up to 300 ms is acceptable. Long response times can indicate a problem with heavy traffic or a slow server somewhere on the ’Net. If there is a problem reaching the site, you will see one of several error messages: Bad IP address stc.org Your DNS server cannot find an IP address for that host name. You may have typed the name incorrectly. Request timed out The site you are trying to ping did not reply in a reasonable time. The site may be down. Destination host unreachable The router path to this server was blocked. This is the one that indicates a problem in the ’Net, usually in a router table in your own ISP. If you want to get a little more technical, or you are trying to track down a problem, you can try a program that returns more detail. Tracert traces the route your message takes, reporting back on each step of the way. Like Ping, you start Tracert from the DOS command line. C:\WINDOWS >tracert stc.org The response will look something like the one shown in Figure 3. Tracing route to stc.org [204.31.201.1] over a maximum of 30 hops: 1 3 ms 2 ms 2 ms suffice.sufficiently.com [207.207.198.97] 2 36 ms 39 ms 34 ms ha-cs1.dactyl.eclipse.net [207.207.199.58] 3 40 ms 36 ms 36 ms dactyl.njw1.eclipse.net [207.207.199.57] 4 65 ms 43 ms 47 ms c1.njw.eclipse.net [207.207.198.17] 5 50 ms 47 ms 50 ms titan-charon.eclipse.net [207.207.223.9] 6 53 ms 56 ms 68 ms prn.titan.eclipse.net [207.207.223.6] 7 89 ms 64 ms 62 ms 206.181.58.33 8 77 ms 65 ms 59 ms ttn1-core1-e0.atlas.digex.net [204.192.56.1] 9 76 ms 67 ms 63 ms bwi1-core1-h1-0.atlas.digex.net [165.117.51.66] 10 99 ms 63 ms 66 ms dca1-core3-h4-0.atlas.digex.net [165.117.51.70] 11 72 ms 64 ms 70 ms dca1-core2-f6-0.atlas.digex.net [206.205.249.2] 12 70 ms 85 ms 96 ms iad1-core1-h1-0.atlas.digex.net [165.117.50.89] 13 114 ms 76 ms 88 ms fddi.mae-east.netcom.net [192.41.177.210] 14 134 ms 67 ms 71 ms t3-2.was-dc-gw1.netcom.net [163.179.220.181] 15 144 ms 169 ms 172 ms h1-0.sjx-ca-gw1.netcom.net [163.179.231.221] 16 219 ms 214 ms 261 ms sjx-ca-gw3.netcom.net [163.179.1.3] 17 * * * Request timed out. 18 163 ms 164 ms 179 ms stc.org [204.31.201.1] Trace complete. Figure 3. Results of Tracert This example traces a message from my home network (sufficiently.com) to our ISP (eclipse.net) through Digex, through MAE East, to Netcom and finally to stc.org in 18 steps. (By the way, don’t worry too much about the blank lines with "Request timed out" unless they are a very high percentage of the steps. There are some routers which do not return tracert messages correctly.) Tracert lets you see where any problem is. It might not be your ISP which is having the difficulty. One of the most interesting things is that the route can be different every time. Remember that third router message "Try that other router to get there." When the Internet is working well, it can create traffic diversions to get around bottlenecks. Now if you really want to get serious, let me tell you how to read the router packet traffic . . .

Return to . . .

[News & Views] [STC-PMC Home] [STC Home Page]
Posted September 20, 1997 (rst)