Sometimes an end user calls the help desk and boldly proclaims that the Internet is down. However, usually the user’s connection
to the Internet is down. In fact, quite often, just one missing link in
a chain of events typically leads that user from his or her desktop out
to the Internet.
This section
explores several places that could be at fault should a user report that
the Internet—or, more likely, that his or her connection to the
Internet—is down.
Two
approaches exist to troubleshooting Internet connectivity problems: from
the top down or from the bottom up. That is, you can troubleshoot from
the server connection and work your way closer to the client, or you can
start at the client and see how far you can connect.
Neither approach is
strictly better than the other. On one hand, starting from the client’s
machine and working up could be better and faster; but traveling to the
desktop could be a hassle and be a slow start. On the other hand,
starting from the server and working down could be quicker if you spot
the problem right away; but if you can’t find it right away, you could
be potentially led down different network paths back to the client—none
of which are really a problem.
Therefore, the best
advice in troubleshooting these kinds of errors is to troubleshoot from
the bottom up and travel to the client and work your way back through
your network and out to the Internet.
Identifying the Specific Networking Issue
The
first problem to gauge in troubleshooting connectivity to the Internet
is to decide whether the problem is network related or name resolution
related. The following sections take a look at each scenario.
Identifying Connectivity Issues
To verify whether it is a
connectivity issue, you should start your journey with the Ping command.
For instance, take a look at the example shown in Figure 12-16.
If
you look closely, you can already get a clue about what might be wrong
with this user’s ability to connect to the Internet. Specifically,
notice that Ping is returning the proper name of the target address
(tailspintoys.com), but the Ping requests themselves are not making it
through to the target. Therefore, name resolution to a DNS server is
likely working properly, but the packets are probably not reaching their
final destination.
The next most logical
tool to use is PathPing, which shows you each route between the client
and the target and helps you determine which link is not passing the
packet on to the next destination.
Identifying Name Resolution Issues
Figure 2 shows another example that you might encounter.
Here, the result
returns no sign that the name resolution is occurring. In this
situation, the next logical step is to verify the user’s DNS settings
and server to ensure that both are returning the values expected from
the Ping operation.
Check to see that the
client’s network adapter is using a DNS server that is part of your
network. (Use the materials found in the next section, “Verifying the Computer’s Network Settings.”)
Important
In
general, a client machine should be pointing at one of your internal
DNS servers rather than using your ISP DNS server settings. |
If you suspect DNS
name resolution issues for your internal servers, you should next run
the Nslookup command from the client system. Nslookup can help you
determine whether your client is getting the right records returned from
the DNS server you have told it to use.
See Also
An excellent primer article on Nslookup can be found at Microsoft Knowledge Base article 200525. |
If you suspect
DNS name resolution issues for names beyond the scope of this particular
server, or if name resolution issues exist for names outside your
company, you should next check the DNS server itself. First, make sure
the DNS server is forwarding to the next logical place based on your
network design. You perform this task by verifying the Forwarders tab,
as shown in Figure 3.
Typically, the DNS server
forwards to a server with more knowledge of the network layout, or
directly to the ISP itself. If this is not the case, you need to adjust
the settings on the Forwarders tab.
Additionally,
verify that the server itself is responding to requests and that it can
also respond to tests on servers to which it forwards information. In
the example shown in Figure 4,
the server itself is responding to resolution requests; however, it is
unable to get any resolution from servers to which it forwards.
This failure could indicate that the name resolution is not on your servers, but rather on servers on which your servers rely.
