Troubleshooting TCP/IP

  • Artikel

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Troubleshooting

What problem are you having?

  • Getting 169.254.y.z address.

  • Host name resolution is failing.

  • Unable to add a default gateway.

  • System error 53 occurred.

  • Cannot connect to a specific server.

  • Long connect times when using Lmhosts for name resolution.

  • TCP/IP connection to a host appears to have stopped.

  • Cannot ping across a local router when using a dial-up connection.

  • A "The registry subkey already exists" message is displayed.

Getting 169.254.y.z address.

Cause:  Through Automatic Private IP Addressing (APIPA), an IP address in the range 169.254.0.1 to 169.254.255.254 with a subnet mask of 255.255.0.0 is automatically assigned when TCP/IP is configured to obtain an IP address automatically, a Dynamic Host Configuration Protocol (DHCP) server is not available, and an alternate configuration is not specified. APIPA is designed to provide automatic IP addressing on single segment networks.

Solution:  Disable automatic address configuration, determine and fix the cause of the computer's inability to contact the DHCP server, or specify an alternate configuration.

See also:  New features for TCP/IP; Configure TCP/IP for an alternate configuration; Disable automatic address configuration

Host name resolution is failing.

Cause:  Host name resolution techniques are failing to resolve a host name to its IP address.

Solution:  The Windows Server 2003 family includes several basic TCP/IP tools that you can use to troubleshoot address and name resolution problems, including the ping command. If you receive the correct response when you use the ping command with an IP address but an incorrect response when you use ping with the host name or NetBIOS name, there is a name resolution problem.

When you use TCP/IP tools such as the ping command, the Hosts file or a DNS server is used for name resolution. You can find the Hosts file in the systemroot\System32\Drivers\Etc folder. This file is not dynamic; you must manually add entries. The format of the file is as follows:

IP address         Friendly name

172.16.48.10   server1   # Remarks are denoted with a #.

When you use a Hosts file for name resolution, the following steps occur:

  1. A user at Computer A enters a command by using the host name of Computer B.

  2. The Hosts file on Computer A (in the systemroot\System32\Drivers\Etc folder) is parsed. When the host name of Computer B is found, it is resolved to an IP address.

The following problems can occur because of errors related to the Hosts file:

  • The Hosts file or the DNS server does not contain the particular host name.

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

  • An invalid IP address is entered for the host name in the Hosts file.

  • The Hosts file contains multiple entries for the same host on separate lines; if so, the first entry from the top of the file is used.

  • A mapping for a computer name-to-IP address was mistakenly added to the Hosts file, rather than the Lmhosts file.

For DNS server host name resolution, verify that the correct DNS servers are configured and in the proper order. You can use the ipconfig /all command to check the current TCP/IP configuration and the ping command to check connectivity with your DNS servers. You can use the nslookup command to send DNS name queries to your primary DNS server.

If you use a DNS server for host name resolution, the name resolution steps are similar. Computer A sends a DNS name query to its configured DNS server. The DNS server resolves the host name of Computer B to an IP address and sends the results back to Computer A.

See also:  Host name resolution; Ipconfig; Ping; Nslookup; Verify DNS registration for domain controllers using the nslookup command; TCP/IP database files

Unable to add a default gateway.

Cause:  The IP address of the default gateway is not on the same IP network ID as your IP address.

Solution:  Find out whether the default gateway is located on the same logical network as the network adapter of the computer by comparing the IP address of the default gateway with the network IDs of any of the network adapters of the computer.

For example, a computer with a single network adapter that is configured with an IP address of 192.168.0.33 and a subnet mask of 255.255.0.0 requires that the default gateway be of the form 192.168.y.z because the network ID portion of the IP interface is 192.168.0.0.

See also:  IP addressing; Subnet masks; Default gateways

System error 53 occurred.

Cause:  System error 53 is returned if name resolution fails for a particular computer name when the net use command is used.

Solution:  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 Lmhosts file or the WINS database. If all TCP/IP elements appear to be installed properly, use the ping command with the remote computer to verify that its TCP/IP software is working.

See also:  Test a TCP/IP configuration by using the ping command; Test TCP/IP connections by using the ping and net view commands; Net use; Ping

Cannot connect to a specific server.

Cause:  Either NetBIOS name resolution is failing to resolve the name or the wrong IP address is being resolved.

Solution:  Use the nbtstat -n command on the server to determine what names the server registered on the network. The computer name of the computer you are trying to connect to should be on the displayed list. If the name is not listed, try one of the other unique computer names displayed by nbtstat.

If the name being used by a remote computer is the same as the name displayed by the nbtstat -n command, then make sure that the remote computer has an entry for the server name on the WINS server or in its Lmhosts file.

See also:  NetBIOS name resolution; Test TCP/IP connections by using the ping and net view commands; Net use; TCP/IP database files; Nbtstat

Long connect times when using Lmhosts for name resolution.

Cause:  The Lmhosts file is parsed sequentially to locate entries without the #PRE option.

Solution:  Place frequently used entries near the top of the file and place the #PRE entries near the bottom. If an entry is added to the end of a large Lmhosts file, mark the entry in Lmhosts as a preloaded entry by using the #PRE option. Then use the nbtstat -R command to update the local name cache immediately.

See also:  TCP/IP database files; Nbtstat; View the NetBIOS name table by using the nbtstat command; Release and refresh NetBIOS names by using the nbtstat command

TCP/IP connection to a host appears to have stopped.

Cause:  Either data is blocked in TCP and UDP queues or there are network or user-level software delay problems.

Solution:  Use the netstat -a command to show the status of all activity on TCP and UDP ports on the local computer.

The state of a good TCP connection is usually established with 0 bytes in the send and receive queues. If data is blocked in either queue, or if the state is irregular, there is probably a problem with the connection. If not, you are probably experiencing a network or user-level software delay.

See also:  Netstat; View current TCP/IP protocol and connection statistics

Cannot ping across a local router when using a dial-up connection.

Cause:  This problem occurs if the Use default gateway on remote network check box is selected on the General tab in the Advanced TCP/IP Settings dialog box (in the Internet Protocol (TCP/IP) dialog box on the General or Networking tab for the properties of the dial-up connection).

This feature adds a default route to the IP routing table that is used instead of the current default route for the duration of the connection. The new default route causes network traffic for IP addresses that are not resolved by other entries in the routing table to be sent across the dial-up connection. This new default route is needed when you dial an Internet service provider (ISP) and use Internet utilities, such as a Web browser or FTP, to access Internet resources.

Solution:  If you want to ping or otherwise connect to computers in a remote network segment across a local router while you are connected as a dial-up client to an ISP, then use the route add command to add the route of the network segment you are attempting to reach by specifying the destination network and subnet mask of the remote network segment and the IP address of the local router.

See also:  Route

A "The registry subkey already exists" message is displayed.

Cause:  The registry keys for a component being installed already exist.

Solution:  Ensure that all the components of a given TCP/IP service are properly removed, and then remove the appropriate registry subkeys by using the Registry Editor.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

TCP/IP registry keys

If you removed TCP/IP and its related service components, you must also remove the following registry subkeys:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dhcp

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LmHosts

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AdapterName\Parameters\Tcpip

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NetBT

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tcpip

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TcpipCU

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WinSock

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WinSock2

SNMP service registry keys

If you removed the SNMP service components, you must also remove the following registry subkeys:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RFC1156Agent

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Snmp

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Snmp

TCP/IP Printing service registry keys

If you removed the TCP/IP Printing service components, you must also remove the following registry subkeys:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Lpdsvc

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TcpPrint

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LPDSVC

Simple TCP/IP Services registry keys

If you removed the Simple TCP/IP Services components, you must also remove the following registry subkeys:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SimpTcp

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SimpTcp

DHCP service registry keys

If you removed the DHCP service components, you must also remove the following registry subkeys:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DhcpMibAgent

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DhcpServer

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DhcpServer

WINS service registry keys

If you removed the WINS service components, you must also remove the following registry subkeys:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wins

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WinsMibAgent

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Wins

DNS service registry keys

If you removed the DNS service components, you must also remove the following registry subkeys:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dns

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dns

For more advanced TCP/IP troubleshooting information, see Resource Kit.