TCP/IP Troubleshooting: A Structured Approach – Part 3: Repairing Network Connections

If you missed the other parts in this article series please read:

 

 

 

Successful troubleshooting relies on three main pillars: logical thinking, technical understanding, and experience with tools, and this series of articles on TCP/IP troubleshooting is firmly based on these pillars. For example, in my first article of this series, we outlined a structured approach that shows how to logically troubleshoot TCP/IP networking problems on Windows-based networks–logical thinking. Then in my second article we examined how routing tables work on Windows computers–technical understanding. In this article we’ll gain understanding of how the Repair feature works for repairing common problems with network connections–experience with tools. Future articles will continue to touch each of these three bases (logical thinking, technical understanding, and experience with tools) in turn so you can hone your skills as a troubleshooter.

 


Get your copy of Windows Server Hacks!

 

The Repair feature is a powerful tool that is seldom used because it is not well understood. Accessing this feature is easy–just right-click on a network connection in your Networking Connections folder (or on a connection icon in your system notification area) and select Repair from the shortcut menu. When you do this, a dialog box opens and a series of messages appear showing the progress of the repair actions being taken. What happens under the hood here is that a series of command-line actions are being performed, and each progress message displayed indicates one of these actions has been performed. Let’s examine each of these steps that take place when you use Repair to understand what they do and why they are performed.

 

Step 1: DHCP Renew

 

This step only occurs if the network connection is configured to receive its address automatically using DHCP. If you’ve configured the connection manually with a static IP address and other TCP/IP settings, this step is skipped. The command-line action that is being performed here is similar to but not identical to the following familiar command:

 

ipconfig /renew

 

This command attempts to contact the DHCP server from which the computer’s address has been previously leased. If the DHCP server can be contacted, the computer verifies its current TCP/IP configuration with the server to confirm that this configuration is valid. When this command is executed using the Repair feature however, it behaves differently than when you run it from the command line. Instead of sending a unicast DHCP Renew message to the DHCP server from which the computer obtained its DHCP configuration, the command instead sends a broadcast DHCP Renew message to any available DHCP server on the network. The reason this is done is so that if the current TCP/IP configuration on the computer is invalid, the computer can attempt to obtain new TCP/IP settings from any available DHCP server by requesting a new address lease. The effect of performing this step of the Repair process is thus twofold: resolving DHCP configuration problems on the client, and resolving issues with not being able to contact a specific DHCP server on the network.

 

TIP: You can prevent network problems resulting from DHCP server unavailability by implementing DHCP server redundancy on your network. For information about some different ways you can do this, see my article titled Ensuring DHCP Server availability on the O’Reilly network.

 

Step 2: Flush ARP Cache

 

The command-line action that is being performed in this step is as follows:

 

arp –d *

 

This command flushes the contents of the Address Resolution Protocol (ARP) cache on the local computer. ARP is a protocol that is used to resolve IP addresses into media access control (MAC) addresses that are generally hardcoded into LAN adapters. The ARP cache contains recently resolved MAC addresses for IP nodes on the network. These MAC addresses are cached on the computer so that communications with these IP nodes can take place without needing to resolve them repeatedly. If one or more of the entries in the ARP cache are incorrect, network communication may fail with some IP nodes on the network. If the incorrect cache entry is for a node on the local subnet, communication with that node will fail. If the incorrect cache entry is for the default gateway, communication with nodes on remote subnets will fail. The type of network communication failure experienced (whether nodes on the local subnet or on remote subnets) can thus provide an indication of which ARP cache entry is incorrect (provided incorrect ARP cache entries is actually the problem).

 

Step 3: Flush NetBIOS Cache

 

The command-line action that is being performed in this step is as follows:

 

nbtstat –R

 

This command flushes the contents of the NetBIOS cache on the local computer. Running this command also pre-loads any entries in the LMHOSTS file into the cache. On most Windows-based networks, including those on which Active Directory is deployed and DNS is used for name resolution, the legacy NetBIOS name resolution is still used for certain functions. As the NetBIOS names of remote hosts are resolved into their associated IP addresses, either by querying a WINS server or by using NetBIOS broadcasts, these hostname-to-IP-address mappings are added to the NetBIOS cache on the local computer so that communication with remote hosts can take place without needing to resolve them repeatedly. If one or more of the entries in the NetBIOS cache are incorrect, network communication may fail with some IP hosts on the network. If the incorrect cache entry is for a host on the local subnet, communication with that host will fail. If the incorrect cache entry is for the default gateway, communication with hosts on remote subnets will fail. The type of network communication failure experienced (whether hosts on the local subnet or on remote subnets) can thus provide an indication of which NetBIOS cache entry is incorrect (provided incorrect NetBIOS cache entries is actually the problem).

 

Incorrect NetBIOS cache entries can sometimes be caused by stale entries in the WINS database on WINS servers. This is because WINS trumps NetBIOS broadcast name resolution when WINS has been implemented, so corrupt or stale WINS entries can repopulate the NetBIOS cache with incorrect entries even after the cache has been cleared. The solution in this case is to tombstone the incorrect records in the WINS database, flush the NetBIOS cache again and then monitor the cache using the nbtstat –c command to ensure these incorrect entries do not get cached again.

 

Step 4: Flush DNS Resolver Cache

 

The command-line action that is being performed in this step is as follows:

 

ipconfig /flushdns

 

This command flushes the contents of the DHS resolver cache on the local computer. Running this command also pre-loads any entries in the HOSTS file into the cache. As fully-qualified DNS names of remote hosts are resolved into their associated IP addresses by querying a name server (DNS server), these FQDN-to-IP-address mappings are added to the DNS resolver cache on the local computer so that communication with remote hosts can take place without needing to resolve them repeatedly. If one or more of the entries in the DNS resolver cache are incorrect, network communication may fail with some IP hosts on the network. To view the current contents of the DHS resolver cache, type ipconfig /displaydns at a command prompt.

 

If the IP address of the remote host you are trying to resolve has recently changed, then you may not be able to connect with that host using its FQDN until you flush your DNS resolver cache. Of course, cache entries will time out by themselves using their specified TTLs obtained from the name server during name resolution, but if you notice that suddenly you can’t connect to some remote host you could try repairing your network connection which flushes the DNS resolver cache like this.

 

Step 5: Register again with WINS

 

The command-line action that is being performed in this step is as follows:

 

nbtstat –RR

 

This command attempts to re-register the local computer in the WINS database on WINS servers. What this means is that all NetBIOS names for the local computer are first released and then renewed in the database. This is only useful of course if your network has WINS servers, but most enterprise environments that have Active Directory deployed and also have Exchange Server deployed generally still use WINS, see KB 837391 for more info.

 

When a Windows computer is shut down properly, it should release its records from the WINS database. If a computer was not shut down properly, the WINS records for the computer are not removed from the database. Stale records in the WINS database can cause network communication problems, especially for portable computers like laptops that may be removed from one network and attached to another. Using the Repair feature can often resolve these problems by forcing the computer to re-register with WINS.

 

Step 6: Register again with DNS

 

The last command-line action that is performed when you use the Repair feature is this:

 

ipconfig /registerdns

 

This command attempts to re-register the local computer in the DNS database on name servers. What this means is that all DNS names for the local computer are first released and then renewed in the DNS database (assuming you have an Active Directory network that uses Dynamic DNS or DDNS for registering DNS names in the database).

 

Conclusion

 

The Repair feature for network connections is a useful tool for troubleshooting network connectivity problems. Unfortunately most administrators are not aware of how this feature works, and this article has attempted to rectify this by providing an under-the-hood look at what goes on when you use this tool. Knowing how this tool works helps you narrow the focus of your troubleshooting efforts by eliminating possible causes such as incorrect or missing DHCP configuration settings, invalid entries in the ARP, NetBIOS or DNS resolver cache, or invalid or stale entries in the WINS or DNS database. If you’re having problems with network connectivity and you’ve verified that your network connection is in a media-connected state (i.e. no loose cable or powered-down hub or switch) then the Repair feature should be one of the first things you should try to resolve the issue and restore connectivity.

 

If you missed the other parts in this article series please read:

 

 

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top