Troubleshooting TCP/IP Connectivity (part 2)

Last time around we began our discussion of troublesho= oting TCP/IP connectivity by looking at ping and tracert, two tools that help troubleshoot physical connectivity. This time around we’re going to look at the more complex topic of troubleshooting name resolution problems, which can be a common source of frustration for administrators of TCP/IP-based networks. We’ll be looking at client-side name resolution both as it applies to networks using NetBIOS-based naming (WINS servers, LMHOSTS files) and DNS-based naming (DNS servers, HOST files).

Troubleshooting Client-side Name Resolution

If the user is able to ping your workstation by IP add= ress, you know that physical connectivity is there. The next step would be to see= if the user can ping your NetBIOS computer name and DNS host name as applicabl= e. This will tell you whether WINS and/or DNS are resolving names properly. If= it fails for the user but not for you, check the rest of their TCP/IP settings= in winipcfg or ipconfig /all and see if the appropriate entries are there for WI= NS and DNS servers. Since name resolution is working fine for you but not for = the user, you wouldn’t expect a problem to be with the name server itself= . If both of you had problems, you would want to begin troubleshooting the name servers.

Troubleshooting name resolution problems is dependent = on what type of name resolution you are running in your organization. Unless y= our network is pure Win2K or pure non-Microsoft, you are most likely running WI= NS to support your Windows 9x/NT hosts. That also means your troubleshooting w= ill involve NetBIOS names. If you are running DNS for name resolution, either in conjunction with WINS or by itself, you will be troubleshooting DNS host na= mes.

Since the problem we’re dealing with involves one client PC, as we’ve said, we’re not expecting to find a server-based problem. As part of the eliminating variables process though, = we would want to take the server out of the equation. To do this, we’ll first see if we can ping the name server (above we already determined that = we had the correct addresses listed). If we can ping the IP address of the ser= ver, we know that we have connectivity. If we can’t ping the name server by IP, we are back to troubleshooting physical connectivity (cabling, hub/swit= ch ports) between the workstation and the server.

Once we know we’re able to ping the name server = as well by IP but not by name, we’ll take the troubleshooting step of ad= ding a HOSTS or LMHOSTS file to the problem computer. HOSTS files are used with = DNS host names, and LMHOSTS files are used with NetBIOS names. In either case, neither file should have an extension. If you create the file in a text edi= tor such as notepad, you might have to go into Explorer and rename the file to remove the .txt extension that is automatically appended to it when you sav= e.

For Windows 9x systems, the file should reside in the \Windows directory. For NT-based systems, the file should be placed in the \winnt\system32\drivers\etc directory. The format of the file would be as follows (you just need one file depending on which name resolution method y= ou are using):

HOSTS

# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.

# This file contains the mappings of IP addresses to host names. Each

# entry should be kept on an individual line. The IP address should

# be placed in the first column followed by the corresponding host name.

# The IP address and = the host name should be separated by at least one

# space.

# Additionally, comments (such as these) may be inserted on individual

# lines or following the machine name denoted by a '#' symbol.

# For example:

# 102.54.94.97 rhino.acme.com = # source server

# 38.2= 5.63.10 x.acme.com = # x client host

127.0.0.1 localhost

192.168.0.10 &= nbsp; ns.company.com

192.168.0.11 &= nbsp; ns2.company.com

192.168.0.21 &= nbsp; mail.company.com

LMHOSTS

# This is a sample LMHOSTS file used by the Microsoft TCP/IP for Windows.

# This file contains the mappings of IP addresses to computernames

#= (NetBIOS) names. Each entry should be kept on an individual line.

# The IP address shou= ld be placed in the first column followed by the

# corresponding computername. The address and the computername

# should be separated= by at least one space or tab. The "#" character

# is generally used t= o denote the start of a comment

# Following any entry in the file with the characters "#PRE" will cause<= /o:p>

# the entry to be preloaded into the name cache. By default, entries are

# not preloaded, but = are parsed only after dynamic name resolution fails.

# Following an entry = with the "#DOM:<domain>" tag will associa= te the

# entry with the domain specified by <domain>. This affects how the

# browser and logon services behave in TCP/IP environments. To preload

# the host name associated with #DOM entry, it is necessary to also add a

#= #PRE to the line. The <domain>= is always preloaded although it will not

# be shown when the name cache is viewed.

# The following example illustrates all of these extensions:

102.54.94.97 mis-pdc #PRE #DOM:networking #net group's DC<= /p>

102.54.94.102 WINS01 #PRE &= nbsp; #WINS server

102.54.94.123 mail = = #mail server

102.54.94.117 WINS02 = #PRE = #WINS server

The above are just modified sample files that are incl= uded with Windows (HOSTS.sam and LMHOSTS.sam). The easiest thing to do is modify= the sample and then save it without the extension.

Conversely, a system with a HOSTS or LMHOSTS file cont= aining outdated information can cause name resolution to fail since the client will never attempt to contact a name server. Once it finds a valid entry in the search order, the search stops.

By putting this kind of text file on our PC, we’= re going to be able to resolve any mapping that exists in our file without hav= ing to consult a name server. This process is quicker since no network communications are involved, and eliminates the name servers as a possible culprit for the problem. The order in which name resolution takes place is a bit complicated and beyond the scope of this article, but typically the sys= tem will check if it is the host being queried, then the HOSTS file, then any configured DNS servers, and if still unable to resolve the name it will use NetBIOS methods based on the node type configured on the client to check the local name cache, check the LMHOSTS file, contact configured WINS servers, = and broadcast to the entire network.

If, after adding a HOSTS file or LMHOSTS file you are = able to connect to network resources by name, you might suspect a corrupted entr= y on the name server. If you’re still not able to ping by name, you might = have a problem with your local name cache. Also, if we’re able to ping the name server by its computer name, but other hosts such as your workstation = or other servers are not able to be reached by name, the problem would most li= kely reside in name caching.

Troubleshooting DNS names with NSLOOKUP

If you are using DNS to resolve names on your network, nslookup (short for name server lookup) is a valuable administrative tool t= hat is installed as part of the TCP/IP protocol suite on NT-based systems such = as NT 4.0, Windows 2000, and Windows XP/.NET. Windows 9x systems require that = you download a third party nslookup utility in order to have the functionality.=

Nslookup is run from a command prompt and is used to r= esolve a host name into an IP address, and even can be used to resolve an IP addre= ss into a host name if a reverse lookup zone has been configured for the domai= n. There are many options available for nslookup, and we could even write a wh= ole article just on this utility, but for here we will stick to the basic usage= . To perform a lookup, simply type nslookup <hostname>= . The host name should be in DNS format, and it is necessary to point out tha= t if you don’t specify a fully qualified domain name (FQDN), nslookup will append the default domain suffix when searching. You can therefore perform = an nslookup against a partial name if desired, knowing that the domain name wi= ll be appended. This can cause undesired behavior though if the client isnR= 17;t setup properly or you aren’t careful in your query, so keep that in m= ind when not using FQDNs. The following shows the output of an nslookup:

In the first nslookup example above, we attempt to loo= kup a host on the Internet. We see a “non-authoritative answer,” which means that our name server was not able to resolve the name directly and ha= d to contact other servers on the Internet to resolve the name. In the second example we query a partial host name, which we see gets appended with our default DNS suffix. In the third example we query the same machine and spec= ify the FQDN, and get the same result.

The above of course illustrates a working DNS name resolution process. When you are troubleshooting broken name resolution on a client, you would look for things such as if the proper DNS suffix was being appended, and if the name server being queried w= as the correct one. By default the primary DNS server listed on the client is the server that is queried, but you can change which server is queried by simply specifying it after the name to query. An example would be: nslookup www.microsoft.com ns1.algx.net. That command would query the name server ns1.algx.net for the host www in the Microsoft.com domain.

Checking the NetBIOS Name Cache

One of the best TCP/IP troubleshooting tools that you = have built into Windows is nbtstat. No matter which version of Windows you are running, you can execute this command with the appropriate switch to ob= tain information about your local NetBIOS name cache or even a remote computer’s cache. By running nbtstat /? yo= u get the following help:

Since we’re concerned with the local name cache = on the PC that is having trouble, we have a couple of options. If you are remotely troubleshooting the PC, you can use the –a or –A options from your workstation against the problem PC. Below we see the resu= lts of using nbtstat against the IP address of a remote machine:

By looking at the list of name registrations, we can determine several things about the configuration of the machine. The hex co= de in < > next to the name in the list is especially helpful, and a breakdown of the above list follows:

Code = Meaning

<00&= gt; &= nbsp; Workstation Service running on the computer in the NAME column when the TYPE is Uniq= ue

<20> = &nb= sp; File server service running on the computer in the NAME column

<00> = &nb= sp; The domain the workstation is logged into when the typ= e is Group

<1C> = Indicates that the machine is a domain controller when= name is the domain

<1B> = Indicates the machine is the domain master browser

<03&= gt; &= nbsp; The NetBIOS name of the workstation, the Messenger service, and the user curren= tly logged in

<1C&= gt; &= nbsp; Indicates IIS services running when name is INet~Services

&n= bsp;

By viewing the name table, we can quickly determine wh= at user account (if any) is logged on to the network, what domain they are log= ged into (if any), and what their computer name is. This will tell you if the problem the user is having accessing resources is related to not being logged in properly.

Other uses of nbtstat are to view the list of currently cached names (nbtstat –c), and to view the statistics regarding names that have been resolved or registered via broadcast or through a WINS server (nbtstat –r). These command only work against the local name cache, so you must execute them at the machine in question. Nbtstat –c is especially helpful in the situation we’ve been describing, because you might find bad entries that are causing the name resolution problems. Nbtst= at –r will show you if the machine is relying largely on name server resolution, or if it is having to broadcast to r= esolve names. If you are using WINS you should have a very high percentage of the resolved and registered names in this table as being name server, rather th= an broadcast. A high percentage of broadcast name resolutions and registrations should indicate a problem with the name resolution process. Your troubleshooting steps would then be to determine if other machines exhibit = the same type of behavior, or if it is localized to this individual computer.

Summary

Troubleshooting TCP/IP connectivity is not too much tr= ouble once you become familiar with the tools at your disposal and follow a simple system to isolate the problem. You’ll find that most problems are eas= ily identifiable based on knowing a few details such as if the configuration ev= er worked, when it stopped working, and whether any changes were made that the= problem can be traced to. Start by assessing physical connectivity with the ping= utility, then move on to tracert and into more complex name resoluti= on utilities. Soon you will be resolving basic network problems very quickly a= nd will increase your value to your users and to your company as a whole.

Questions or comments? Will can be reached at WWillis@Transcender.com