WINDOWS 1002000 PROFESSIONAL RESOURCE KIT [Electronic resources] نسخه متنی

Perform TCP/IP Troubleshooting

Many network troubleshooting tools are available to assist in diagnosing TCP/IP problems for Windows 2000 Professional. This section summarizes the most common and most helpful tools included with the operating system, and provides an organized approach for deploying them.

Assess the situation. After assessing the TCP/IP problem, create a plan to determine the true nature of the problem: IP addressing and routing, host name resolution, NetBIOS name resolution, or IP security. A flowchart is provided to assist you in this task in Figures 22.24 through 22.26. See "TCP/IP Troubleshooting Overview" in this chapter.

Determine and obtain required troubleshooting tools. After you have determined the possible source of the problem, obtain the tools that you need to prove your hypothesis and resolve the problem. See "TCP/IP Troubleshooting Tools" in this chapter.

Determine and resolve name resolution problems. First, determine whether the error condition was caused by a failure in host (for example, www.reskit.com) or NetBIOS (for example, computername) name resolution. Use the tools to determine the nature of the IP-to-name resolution problem. See "Troubleshooting Name Resolution" in this chapter.

Determine and resolve IP addressing problems. If name resolution is not the nature of the TCP/IP problem, verify that IP addressing, routing, IP security and filtering have been correctly configured on the Windows 2000 Professional-based client. Additionally, confirm that the route to the remote computer is properly configured and available. See "Troubleshooting IP Addressing" in this chapter.

Determine and resolve IP routing problems. If the nature of the TCP/IP problem occurs outside the current subnet, or is related to access of a remote host or router, verify the configuration of the routing table gateways, and check the status of routers along the route path. See "Troubleshooting Routing" in this chapter.

TCP/IP Troubleshooting Overview

When troubleshooting any problem, ask yourself the following questions:

What application is failing? What works? What doesn't work?

Is the problem basic IP connectivity or is it name resolution? If the problem is name resolution, does the failing application use NetBIOS names or DNS names and host names?

How are the things that do and don't work related?

Have the things that don't work ever worked on this computer or network?

If so, what has changed since they last worked?

Ideally, a review of the location and timing of the problem helps narrow the problem's scope. In addition, you can examine TCP/IP failures systematically by referring to the steps needed for successful computer communications.

TCP/IP for Windows 2000 allows an application to communicate over a network with another computer by using three basic types of destination designations:

IP address (for example, 172.10.1.32)

Host name (for example, client1.reskit.com)

NetBIOS name (for example, client1)

This section describes how to troubleshoot either host name or NetBIOS name resolution problems. Both of these issues are outlined in Figures 22.23 through 22.25, which provide a simplified flowchart to guide troubleshooting.

Figure 22.23 TCP/IP Troubleshooting Flowchart (Part 1 of 3)

Figure 22.24 TCP/IP Troubleshooting Flowchart (Part 2 of 3)

Figure 22.25 TCP/IP Troubleshooting Flowchart (Part 3 of 3)

The first step is to determine which application is failing. Typically, this is Telnet, Internet Explorer, net use, or another application that uses NetBIOS or Sockets to find network resources. Making this determination helps with the next step, which is to determine whether the problem is a host name or NetBIOS name resolution problem.

The easiest way to distinguish host name problems from NetBIOS name resolution problems is to find out whether the failing application uses NetBIOS or Sockets. If it uses Sockets, the problem lies with a DNS/host name resolution. If the application uses NetBIOS, the problem is with NetBIOS name resolution (broadcast, Lmhosts or WINS). Among the most common applications, the NetBIOS family includes the various net commands or the Windows NT 4.0 administrator tools. Most Internet- or intranet-based applications such as Internet Explorer and other web browsers, ftp clients and telnet use Windows Sockets.

TCP/IP Troubleshooting Tools

Table 22.12 lists the diagnostic tools discussed in this section. There are other troubleshooting tools available for TCP/IP; they are described in more detail in "Troubleshooting Tools and Strategies" in this book.

Table 22.12 TCP/IP Diagnostic Tools

To view the proper syntax for each command, type /? after each command.

In addition to the TCP/IP-specific tools, the following Microsoft Windows 2000 tools and utilities might be needed in problem determination and resolution:

Event Viewer—Tracks system errors and events.

Control Panel—Allows changes to networking and other system components.

Registry editors—Both Regedit.exe and Regedt32.exe allow viewing and editing of registry parameters.

The following section details the procedures for detecting and resolving a variety of host and NetBIOS name resolution problems.

NetBIOS Name Resolution

The following section describes the methods for detecting and resolving the most common types of NetBIOS name resolution problems.

Resolving NetBIOS Error 53

The most common symptom of a problem in NetBIOS name resolution is when the Ping tool returns an Error 53 message. The Error 53 message is generally returned when name resolution fails for a particular computer name. Error 53 can also occur when there is a problem establishing a NetBIOS session. To distinguish between these two cases, use the following procedure:

To determine the cause of an Error 53 message

From the Start menu, open a command prompt.

At the command prompt, type:

net view * <hostname>

where <hostname> is a network resource you know is active.

If this works, your name resolution is probably not the source of the problem. To confirm this, ping the host name, as name resolution can sometimes function properly, yet net use returns Error 53 (such as when a DNS or WINS server has a bad entry). If Ping also shows that name resolution fails (by returning the "Unknown host" message), check the status of your NetBIOS session.

To check the status of your NetBIOS session

From the Start menu, open a command prompt.

At the command prompt, type:

net view <ip address>

where <ip address> is the same network resource you used in the earlier procedure. If this also fails, the problem is in establishing a session.

If the computer is on the local subnet, confirm that the name is spelled correctly and that the target computer is running TCP/IP as well. If the computer is not on the local subnet, be sure that its name and IP address mapping are available in the DNS database, the Hosts or Lmhosts file, or the WINS database.

If all TCP/IP elements appear to be installed properly, use Ping with the remote computer to be sure its TCP/IP protocol is working.

Check the Lmhosts File

The name resolution problem might be in your Lmhosts file, which looks for addresses sequentially from the top down. If more than one address is listed for the same host name, TCP/IP returns the first value it encounters, whether that value is accurate or not.

You can find the Lmhosts file in %SystemRoot%System32DriversEtc. Note that this file does not exist by default; a sample file named Lmhosts.sam exists. This file must be renamed to Lmhosts before it is used.

NOTE

---

While %SystemRoot%System32DriversEtc is the default directory for this file, exactly which Lmhosts file is consulted depends on the value of the databasepath registry entry located in: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices TcpipParameters

The database path tells the local computer where to look for the Lmhosts file.

Check the WINS Configuration

Make sure your computer's WINS configuration is correct. In particular, check the address for the WINS server.

To examine your WINS configuration

In Control Panel, double-click Network and Dial-Up Connections.

Right-click Local Area Connection, and then click Properties.

In the Local Area Connection Properties dialog box, select Internet Protocol (TCP/IP), and then click Properties.

In the Internet Protocol (TCP/IP) Properties dialog box, click Advanced.

In the Advanced TCP/IP Settings dialog box, click the WINS tab.

In the WINS configuration dialog box, add the server's IP address (if none is listed) and check to see whether Lmhosts lookup is enabled. Also check to see whether NetBIOS over TCP/IP is taken from the DHCP server, enabled, or disabled. If you are using DHCP for this host computer, take the value from the DHCP server. Otherwise, enable NetBIOS over TCP/IP.

Host and DNS Name Resolution

If the problem is not NetBIOS but Sockets, the problem is related to either a Hosts file or a DNS configuration error. To determine why only IP addresses, but not host names, work for connections to remote computers, make sure that the appropriate Hosts file and DNS setup have been configured for the computer.

To check host name resolution configuration

In Control Panel, double-click Network and Dialup Connection.

Right-click Local Area Connections, and then select Properties.

Click on Internet Protocol (TCP/IP), and then click Properties.

In the Microsoft TCP/IP Properties dialog box, click the Advanced tab.

Click the DNS tab.

Confirm that DNS is configured properly. If the DNS server IP address is missing, add it to the list of DNS server addresses.

Note that this procedure does not take DHCP clients into account; these clients do not have DNS servers in the list.

Check the Hosts File

If you are having trouble connecting to a remote system using a host name and are using a Hosts file for name resolution, the problem might be with the contents of that file. Make sure the name of the remote computer is spelled correctly in the Hosts file and by the application using it.

The Hosts file or a DNS server is used to resolve host names to IP addresses whenever you use TCP/IP tools such as Ping. You can find the Hosts file in %SystemRoot%System32DriversEtc.

This file is not dynamic; all entries are made manually. The file format is the following:

172.16.48.10            testpc1  # Remarks are denoted with a #.

The IP address and friendly host name are always separated by one or more space or tab characters.

The following Hosts file problems can cause networking errors:

The Hosts file does not contain the particular host name.

The host name in the Hosts file or in the command is misspelled.

The IP address for the host name in the Hosts file is invalid or incorrect.

The Hosts file contains multiple entries for the same host on separate lines. Because the Hosts file is parsed from the top, the first entry found is used.

Check Your DNS Configuration

If you are using DNS, be sure that the IP addresses of the DNS servers are correct and in the proper order. Use Ping with the remote computer's host name, and then use its IP address to determine whether the host address is being resolved properly. If the host name ping fails and the IP address ping succeeds, the problem is with name resolution. You can test whether the DNS servers are running by pinging their IP addresses or by opening a Telnet session to port 53 on the DNS server. If the connection is established successfully, the DNS service is working on the DNS server. After you've verified that the DNS service is running, you can perform Nslookup queries to the DNS server to further verify the status of the records for which you are looking.

If ping by IP address and by name fail, the problem is with network connectivity, such as basic connectivity or routing. For more information about troubleshooting network connectivity, see "Troubleshooting Routing" later in this chapter.

For a brief summary about how DNS resolves host names, see "Name Resolution Using DNS" earlier in this chapter.

DNS Error Messages

Errors in name resolution can occur when the entries in a DNS server or client are not configured correctly, when the DNS server is not running, or when there is a problem with network connectivity. To determine the cause of any name resolution problem, you can use the Nslookup tool.

Failed queries return a variety of messages, depending on whether the name cannot be resolved, whether the server does not provide a response, or the request times out. The server might be offline, the host computer might not have the DNS service enabled, or there might be a hardware or routing problem.

Troubleshooting IP Addressing

If host name resolution occurs successfully, the problem might lie elsewhere. In this case, the problem might be simply a matter of correcting the IP configuration rather than examining the name resolution process.

TCP/IP troubleshooting generally follows a set pattern. In general, first verify that the problem computer's TCP/IP configuration is correct, and then verify that a connection and a route exist between the computer and destination host by using Ping.

Compile a list of what works and what doesn't work, and then study the list to help isolate the failure. If link reliability is in question, try a large number of pings of various sizes at different times of the day, and plot the success rate or use the PathPing tool.

Check Configuration with Ipconfig

When troubleshooting a TCP/IP networking problem, begin by checking the TCP/IP configuration on the computer experiencing the problem. Use the ipconfig command to get the host computer configuration information, including the IP address, subnet mask, and default gateway.

When Ipconfig is used with the /all switch, it produces a detailed configuration report for all interfaces, including any configured remote access adapters. Ipconfig output can be redirected to a file and pasted into other documents. To do so, type ipconfig >directoryfile name. The output is placed in the directory you specified with the file name you specified.

The output of Ipconfig can be reviewed to find any problems in the computer network configuration. For example, if a computer has been configured with an IP address that is a duplicate of an existing IP address that has already been detected, the subnet mask appears as 0.0.0.0.

If no problems appear in the TCP/IP configuration, the next step is to test the ability to connect to other host computers on the TCP/IP network.

Test Network Connection with Ping and PathPing

Ping is a tool that helps to verify IP-level connectivity; PathPing is a tool that detects packet loss over multiple-hop trips. When troubleshooting, the ping command is used to send an ICMP Echo Request to a target host name or IP address. Use Ping whenever you want to verify that a host computer can send IP packets to a destination host. You can also use the Ping tool to isolate network hardware problems and incompatible configurations.

NOTE

---

If you call ipconfig /all and receive a response, there is no need to ping the loopback address and your own IP address-Ipconfig has already done so to generate the report.

It is best to verify that a route exists between the local computer and a network host by first using Ping and the IP address of the network host to which you want to connect. The command syntax is:

ping <IP address>

Perform the following steps when using Ping:

Ping the loopback address to verify that TCP/IP is installed and configured correctly on the local computer.

ping 127.0.0.1

If the loopback step fails, the IP stack is not responding. This might be because the TCP drivers are corrupted, the network adapter might not be working, or another service is interfering with IP.

Ping the IP address of the local computer to verify that it was added to the network correctly. Note that if the routing table is correct, this simply forwards the packet to the loopback address of 127.0.0.1.

ping <IP address of local host>

Ping the IP address of the default gateway to verify that the default gateway is functioning and that you can communicate with a local host on the local network.

ping <IP address of default gateway>

Ping the IP address of a remote host to verify that you can communicate through a router.

ping <IP address of remote host>

Ping the host name of a remote host to verify that you can resolve a remote host name.

ping <Host name of remote host>

Run a PathPing analysis to a remote host to verify that the routers on the way to the destination are operating correctly.

pathping <IP address of remote host>

NOTE

---

If your local address is returned as 169.254.y.z, you have been assigned an IP address by the Automatic Private IP Addressing (APIPA) feature of Windows 2000. This means that the local DHCP server is not configured properly or cannot be reached from your computer, and an IP address has been assigned automatically with a subnet mask of 255.255.0.0. Restart the Windows 2000 Professional-based computer, and see if the networking problem persists.

If your local address is returned as 0.0.0.0, the Microsoft MediaSense software override started because the network adapter detects that it is not connected to a network. To correct this problem, turn off MediaSense by making sure that the network adapter and network cable are connected to a hub. If the connection is solid, reinstall the network adapter's drivers or a new network adapter.

Ping uses host name resolution to resolve a computer name to an IP address, so if pinging by IP address succeeds, but fails by name, then the problem lies in host name resolution, not network connectivity. For more information about troubleshooting host name resolution, see "Troubleshooting Name Resolution" earlier in this chapter.

If you cannot use Ping successfully at any point, check the following:

The local computer's IP address is valid and appears correctly in the IP Address tab of the Internet Protocol (TCP/IP) Properties dialog box or when using the Ipconfig tool.

A default gateway is configured and the link between the host and the default gateway is operational. For troubleshooting purposes, make sure that only one default gateway is configured. While it is possible to configure more than one default gateway, gateways beyond the first are only used when the IP stack determines that the original gateway is not functioning. Because the point of troubleshooting is to determine the status of the first configured gateway, delete all others to simplify your troubleshooting.

IP Security is not currently enabled. In some cases, IPSec functions interfere with ping packets being sent to or from a remote host. For more information about IPSec, see "Configuring IPSec Policies" earlier in this chapter.

IMPORTANT

---

If the remote system being pinged is across a high-delay link such as a satellite link, responses might take longer to be returned. The -w (wait) switch can be used to specify a longer time-out.

Clear ARP Cache

If you can ping both the loopback address and your own IP address, the next step is to clear out the ARP cache and reload it. This can be done by using the Arp tool. Use commands arp -a or arp -g to display the cache contents. Delete the entries with arp -d <IP address>.

Verify Default Gateway

Next, look at the default gateway. The gateway address must be on the same network as the local host; if not, no messages from the host computer can be forwarded to any location outside the local network. Next, check to make sure that the default gateway address is correct as entered. Finally, check to see that the default gateway is a router, not just a host, and that it is enabled to forward IP datagrams.

Ping Remote Host

If the default gateway responds correctly, ping a remote host to ensure that network-to-network communications are operating as expected. If this fails, use Tracert to examine the path to the destination. For IP routers that are Windows NT or Windows 2000-based computers, use the Route tool or the Routing and Remote Access administrative tool on those computers to examine the IP route table. For IP routers that are not Windows NT or Windows 2000-based computers, use the appropriate tool or facility to examine the IP route table.

Four error messages are commonly returned by Ping during troubleshooting as shown in Table 22.13.

Table 22.13 Ping Error Messages

Check IP Security

IPSec can increase the defenses of a network, but it can also make changing network configurations or troubleshooting problems more difficult. In some cases, IPSec running on a Windows 2000 Professional-based computer can create difficulties in connecting to a remote host. If IPSec is implemented locally, turn off IPSec and attempt to run the requested network service or function.

To disable local IPSec policies

In Control Panel, double-click Network and Dial-up Connections.

Right-click the local area connection you want to change, and then select Properties.

Select Internet Protocol (TCP/IP), and then click Properties.

Click Advanced.

Click the Options tab.

Select IP Security, and then click Properties.

Click Do not use IPSEC, and then click OK.

If IPSec is implemented through IPSec policies at a Windows 2000 domain controller, contact the security administrator to disable the security policy for that computer.

If the problem disappears when IPSec policies are turned off, you know that the additional IPSec processing burden or its packet filtering are responsible for the problem. Contact the security administrator to permanently modify the IPSec policy for the computer.

For more information about IPSec issues, see "Configuring IPSec Policies" earlier in this chapter.

Check Packet Filtering

Any mistakes in packet filtering can make address resolution or connectivity fail. To determine if packet filtering is the source of a network problem, you must disable the TCP/IP packet filtering.

To disable TCP/IP packet filtering

In Control Panel, double-click the Network and Dial-Up Connections.

Right-click the Local Area Connection, and then click Properties.

Select Internet Protocol (TCP/IP), and then click the Properties tab.

Click Advanced, and then click Options.

In the Optional Settings window, click TCP/IP Filtering, and then click the Properties tab.

Clear the Enable TCP/IP Filtering (All Adapters) check box, and then click OK.

Try pinging an address by using its DNS name, its NetBIOS name, or its IP address. If the attempt succeeds, the packet filtering options might be misconfigured or might be too restrictive. For instance, the filtering might permit the computer to act as a Web server, but might in the process disable tools like Ping or remote administration. Restore a wider range of permissible filtering options by changing the permitted TCP, UDP, and IP port values.

If the attempt still fails, another form of packet filtering might still be interfering with your networking. For more information about Routing and Remote Access service filtering functions, see "Unicast IP Routing" in the Internetworking Guide. For more information about IPSec packet filtering, see "Internet Protocol Security" earlier in this chapter.

Troubleshooting Routing

Windows 2000 supports routing on both single- and multi-homed computers with or without the Routing and Remote Access service. The Routing and Remote Access service includes the Routing Information Protocol (RIP) and the Open Shortest Path First (OSPF) routing protocols. Routers can use RIP or OSPF to dynamically exchange routing information.

For more information about TCP/IP routing, see "Unicast IP Routing" in the Internetworking Guide. For information about troubleshooting IP multicast routing, see "IP Multicast Support" in the Internetworking Guide.

Cannot Connect to a Specific Server

To determine the cause of connection problems when trying to connect to a specific server using NetBIOS-based connections, use the nbtstat -n command to determine what name the server used to register on the network.

Nbtstat -n output lists several names that the computer has registered. A name resembling the computer's name as shown on the desktop must be present. If not, try one of the other unique names displayed by Nbtstat.

The Nbtstat tool can also display the cached entries for remote computers from either #PRE entries in the Lmhosts file or from recently resolved names. If the name the remote computers are using for the server is the same, and the other computers are on a remote subnet, be sure that they have the computer's mapping in their Lmhosts files or WINS servers.

Connection to Remote Host Hangs

To determine why a TCP/IP connection to a remote computer is not working properly, use the netstat -a command to show the status of all activity on TCP and UDP ports on the local computer.

A good TCP connection usually shows 0 bytes in the Sent and Received queues. If data is blocked in either queue or if the state is irregular, the connection is probably faulty. If not, you are probably experiencing network or application delay.

Examining the Routing Table with Route

For two hosts to exchange IP datagrams, they must both have a route to each other, or use default gateways that know of a route. Normally, routers exchange information with each other by using a routing protocol such as RIP. For information about how to examine and configure the local route table, see "Configure Local IP Routing Table" earlier in this chapter.

Examine Paths with Tracert

Tracert is a route tracing tool that uses incrementally higher values in the TTL field in the IP header to determine the route from one host to another through a network. It does this by sending ICMP Echo Request messages and analyzing ICMP error messages that return. Tracert allows you to track the path of a forwarded packet from router to router for up to 30 hops. If a router has failed or if the packet is routed into a loop, Tracert reveals the problem. After the problem router is found, its administrator can be contacted if it is an offsite router, or the router can be restored to fully functional status if it is under your control.

Troubleshooting Gateways

If you see the message "Your default gateway does not belong to one of the configured interfaces…" during setup, find out whether the default gateway is located on the same logical network as the computer's network adapter. The easiest way to do this is to compare the network ID portion of the default gateway's IP address with the network IDs of the computer's network adapters. In other words, check that the bitwise logical AND of the IP address and the subnet mask equals the bitwise logical AND of the default gateway and the subnet mask.

For example, a computer with a single network adapter configured with an IP address of 172.16.27.139 and a subnet mask of 255.255.0.0 requires a default gateway of the form 172.16.y.z. The network ID of the IP interface is 172.16.0.0. Using the subnet mask, TCP/IP can determine that all traffic on this network is local; everything else must be sent to the gateway.