لطفا منتظر باشید ...
Tracking Down Problems Beyond Your Control
The preceding section shows you all the tricks for tracking down a local problem. There will be times when a problem lies just beyond your reach. You might have seen indications of such a problem when you ran netstat s. Unfortunately, there's not much you can do about such problems, but you can use some other tools to make sure that the problem lies beyond your control. This section shows you some of those tools as well as how to use them.
Back to ping
You have already seen how to run ping, so you're spared the repeat performance. However, it should be pointed out that it was gathering information earlier. Now you see how to use it to isolate the potential source of connectivity problems.When you have satisfied yourself that your computer is working fine and that the inability to reach a specific destination lies beyond your reach, the next thing you want is to run ping. By using ping to reach that destination, you can immediately tell if the host is accessible. It is entirely possible that the web service on that computer is down even though the computer and its operating system are fine. When that happens, you won't be able to reach it using a browser, but ping returns some valid results. If you have successfully reached the destination using ping, you're done! You have isolated the problem to that destination computer's ability to run its web service.
The Trouble with pingping is a good tool but it is far from perfect. It is a simple, easy-to-use tool for checking the reachability of a destination using either IP addresses or domain names. One of its more notable drawbacks is that it uses ICMP for transportation. If you recall, ICMP enjoys the lowest priority of all TCP/IP protocols. Consequently, ping requests are often just dropped in a busy network or by a busy host.The lack of a response might be interpreted as the host being unreachable when, in fact, it is either too busy to respond at that moment or it is connected to a busy network. Either way, you can get misleading results. Alternatively, a site or network might block all inbound ICMP as a way of increasing security. If so, that would prevent ping from working for you. |
Tracing the Route
If you still can't access that website and have successfully run through the tests shown here, the problem lies beyond your computer. The first thing you want to do is trace the path that your packets are taking. By following that route, you can also see exactly where in the network your attempted connection is failing.The tool you can use to do this is tracert or traceroute, depending on which operating system you are using. Figure 14-18 shows a tracert session to the Cisco Systems website. You trace to the FQDN (www.cisco.com), but you could just as easily trace that route using an IP address.
Figure 14-18. Tracing the Route to www.cisco.com
Time-To-Live (TTL) value of the ICMP Echo request. In simpler words, what you get is a hop-by-hop accounting of the path that lies between you and your targeted destination.The hop count, or number of routers that make up the route, is the first column on the left of the tracert results screen. The next three columns are running totals of the amount of time it took to reach that hop or router. The last column is just the name and IP address of the machine that responded to your tracert request.Looking back at Figure 14-18, you can see that Internet service providers (ISPs) try to use mnemonic names for their routers. This is quite helpful in understanding where your packets are going. The first two lines are the hops needed to get out of my home and onto my ISP's network. That ISP (RCN) carried my packets through Pennsylvania, into Philadelphia (yes, that's part of Pennsylvania!) and then into New York City. In New York City, RCN handed off the packets to Level 3 (another ISP), where it traversed the United States in a single hop. My packets literally went from New York City to San Jose in one hop! In San Jose, my packets were handed off to the BBN Planet network on which it appears the Cisco Systems commercial website is hosted.If you see asterisks (*) followed by the words Request Timed Out, you might be seeing an error. As shown in the preceding figure, my tracert packets reached the Cisco.com domain, but that's where the information stopped flowing. Retries were attempted with no success. This could indicate that the website you're tracing is unavailable. Or, as is the case with this particular website, the asterisks could indicate that security permissions have been defined inside the Cisco.com network that effectively prevent any additional replies to my queries.It is for that reason that tracert is a good, but not perfect, tool. Use it to validate what you are seeing with other tools, but don't rely on it alone to diagnose connectivity problems. For example, having first established that any given destination was accessible by using ping, you might have gotten nothing but asterisks when trying to trace to it. When that happens, feel free to rerun ping just to make sure that the destination was, in fact, still accessible. If ping makes contact but tracert returns asterisks, you can rest assured that security permissions are generating the asterisks.Please keep in mind that the Internet is a dynamic network and that routing decisions about the best path are continuously being reevaluated. Thus, you might run the same exact test just a few minutes apart and see different responses. If so, relax: That's the Internet hard at work picking the best route for you!
