TCP/IP Troubleshooting

Cannot Connect to Remote Systems Using Host Name

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, click the Network and Dialup Connection icon.
Right-click Local Area Connections, and then select Properties.
Click on Internet Protocol (TCP/IP), and then click Properties.
Click the Advanced tab in the Microsoft TCP/IP Properties dialog box.
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 server 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 may 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 utilities such as Ping. You can find the Hosts file in \%SystemRoot%\System32\Drivers\Etc.

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

IP Address     Friendly Name

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.

Host Name Resolution Using a Hosts File

A computer using its Hosts file for name resolution performs the following steps.

Computer A enters a command using the host name of Computer B.
Computer A parses its Hosts file (in \%SystemRoot%\System32\Drivers\Etc), looking for the Computer B host name. When the host name of Computer B is found, it is resolved to an IP address.
The resolved IP address is passed to the IP routing component. The routing component returns either a routing error because a route was not found for the destination IP address or the forwarding IP address and interface over which the packet is to be forwarded cannot be found.
ARP resolves the forwarding IP address to a hardware address.

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 with 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. Once 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 you are looking for.

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

A brief summary of how DNS resolves host names is provided in this section. For more information about DNS, see "Windows 2000 DNS" in this book.

Host Name Resolution Using a DNS Server

DNS is a distributed database that maps domain names to data. A user can query DNS using hierarchical, friendly names to locate computers and other resources on an IP network. This allows it to largely replace the function once performed by the Hosts file. To do so, it resolves friendly names to IP addresses as follows (in the worst-case scenario, an answer might be provided by any server along the line, preventing the need for further iterative queries):

The client contacts the DNS name server with a recursive query for name.reskit.com. The server must now return the answer or an error message.
The DNS name server checks its cache and zone files for the answer, but doesn't find it. It contacts a server at the root of the Internet (a root DNS server) with an iterative query for name.reskit.com.
The root server doesn't know the answer, so it responds with a referral to an authoritative server in the .com domain.
The DNS name server contacts a server in the .com domain with an iterative query for name.reskit.com.
The server in the .com domain does not know the exact answer, so it responds with a referral to an authoritative server in the reskit.com domain.
The DNS name server contacts the server in the reskit.com domain with an iterative query for name.reskit.com.
The server in the reskit.com domain does know the answer. It responds with the correct IP address.
The DNS name server responds to the client query with the IP address for name.reskit.com.

Note that this example is specific to the Internet. For more information about DNS host name resolution, recursive queries, and iterative queries, see "Introduction to DNS" in this book.

DNS Error Messages

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

Failed queries will return a variety of messages, depending on the nature of the failure. For example, if the server cannot resolve the name, it returns a message in the following format:

C:\nslookup <Destination_host>

Server: <fully_qualified_domain_name>

Address: <server_IP_address>

***  <fully_qualified_domain_name> can't find <Destination_host>: Non-existent domain

In other cases, the requests to the DNS service time out without a reply and returns a message in the following format:

C:\nslookup Valid_Host

Server: [IP_Address]

Address: w.x.y.z

DNS request timed out.

timeout was 2 seconds.

If the server fails to answer the request, Nslookup returns an error message in the following format:

C:\nslookup

*** Can't find server name for address <IP_Address>: No response from server

*** Default servers are not available.

This message indicates that the DNS server cannot be reached; it does not indicate why the server is unavailable. The server might be offline, the host computer might not have the DNS service enabled, or there might be a hardware or routing problem.

For more information about DNS troubleshooting, see "Introduction to DNS" in this book.

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%\System32\Drivers\Etc. 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%\System32\Drivers\Etc is the default directory for this file, exactly which LMHOSTS file is consulted depends on the value of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\databasepath registry entry. The database path tells the local computer where to look for the LMHOSTS file.

Long Connect Times Using LMHOSTS

To determine the cause of long connect times after adding an entry to LMHOSTS, take a look at the order of the entries in the LMHOSTS file.

Long connect times can occur when a large LMHOSTS file has the specified entry at the end of the file. To speed up resolution of the entry, mark the entry in LMHOSTS as a preloaded entry by following the mapping with the #PRE tag (see "Nbtstat" earlier in this chapter for an example). Then use the nbtstat -R command to update the local name cache immediately.

Alternately, you can place the mapping higher in the LMHOSTS file. As discussed in the appendix "LMHOSTS File" in this book, the LMHOSTS file is parsed sequentially from the top to locate entries without the #PRE keyword. Therefore, you should always place frequently used entries near the top of the file and place the #PRE entries near the bottom.

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, click the Network and Dial-up Connections icon.
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.