TCP/IP Troubleshooting: A Structured

Approach - Part 3: Repairing Network

Connections
• Launched: Nov 14, 2006
• Updated: Nov 14, 2006
• Section: Articles & Tutorials :: Network Troubleshooting
• Author: Mitch Tulloch

How to use the Repair feature for network connections on Windows platforms.

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.

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.