Network Troubleshooting - for your LAN

If you cannot see the other computers in Explorer's Network Neighborhood, try to view other computers on the network using a Universal Naming Convention (UNC) connection. To do so, follow these steps: 

	Click Start, and then click Run.
	In the Open box type, type the following line
	\\<computername>
	where <computername> is the name of the computer to which you are trying to connect
	Click OK.

NOTE1: to find out the name of a computer, right-click on "My Computer", and select "Properties". The name, and then the Workgroup of that PC will be listed under "Registered To:" The name will be the first line, and the workgroup will be the second line.

NOTE2: make shortcuts on your desktop to the other PC's on your LAN. In the command line for the shortcut, simply type in: \\<computername> 

For example : \\Ken

Getting to the Cause of the Problem

If you can view other computers using a UNC connection, but they still do not show up in Network Neighborhood, consider the following possible causes: 

	Master Browser - each Domain/Workgroup must have one computer that is acting as a Master Browser--if there is an NT computer in the workgroup, then that should be the master browser.  A browse server may not be selected on the network. In a Windows 98 network, a computer that maintains a list of workgroup servers is selected. In a worst-case scenario, it can take anywhere from 5 to 15 minutes to establish a browse server. If no browse server exists, you cannot browse computers on the network, and they won't show up in Network Neighborhood !!
	There may be a network cabling problem or a problem with the other computer's network adapter configuration. This can be the case if only the local computer appears in Network Neighborhood.
	For Win95 machines, File/Print sharing must be enabled (hence, the File/Print sharing service is installed) for those machines to show up under Network Neighborhood. (Note, nothing has to be actually shared out--just the service needs to be installed).
	WINS - all the computers you want to browse must use the same WINS server (or servers in the case of primary/secondary)
	If you are using BlackIce as a firewall,  Go to "Tools/Edit BlackIce Settings . . . Firewall tab", and check : Allow NetBIOS Neighborhood. This allows other computers to show up in Network Neighborhood !!!

Name Resolution - i.e. Showing up in Network Neighborhood

*** see also WinNT Name Resolution    Name Resolution for Complex TCP/IP Network    

                    NetBIOS over TCP/IP and WINS Resolution    

To see the other computers in Network Neighborhood (or Network Places) - each computer on a LAN, must know the MAC address, IP address, and the Name (friendly name)of every other computer on the LAN.  For example, my own PC is called "Dad", my IP is 192.168.1.102, and my MAC is 00-04-75-B5-A7-4B.

• Every computer on a TCP/IP internetwork must be given a unique computer name and IP address. The IP address identifies both the computer and the subnetwork to which it is attached. When the computer is moved to a different subnetwork, the IP address must be changed to reflect the new subnetwork ID.
• Name Resolution Services. People use "friendly" names to connect to computers; programs use IP addresses. TCP/IP internetworks require a name resolution service that converts computer names to IP addresses and IP addresses to computer names.

Name resolution is the process of identifying the other computers on your LAN.  It is done in a specific order:

1. DNS or WINS are checked

2. if no DNS or WINS servers are found, your computer then looks in the LMHOSTS or HOSTS files

3. finally, it broadcasts an ARP out onto the network

NetBIOS over TCP/IP is the network component that performs computer name to IP address mapping, name resolution (Netbt.sys in WinNT-2000-XP and Vnbt.vxd in Win95 and Vnbt.386 in Win98). There are currently four NetBIOS over TCP/IP name resolution methods: b-node, p-node, m-node and h-node.

• b-node, which uses broadcast messages to resolve names
• p-node, which uses point-to-point communications with a name server to resolve names
• m-node, which first uses b-node and then — if necessary — p-node to resolve names
• h-node, which first uses p-node for name queries and then b-node if the name service is unavailable or if the name is not registered in the database

The two most common node types for client computers are b-node (the default) and h-node. 

B-Node - when using b-node, broadcasts are used for both name registration and name resolution. On a TCP/IP network, if the IP router is not configured to forward the name registration and name query broadcasts, systems on different subnets will not be able to see each other since they will not receive the broadcasts. B-node name resolution is not the best option on larger networks because its reliance on broadcasts can load the network with broadcasts.
Microsoft Modified B-Node

Modified B-node - the TCP/IP used in Microsoft Windows NT uses a modified version of b-node name resolution. Microsoft modified b-node name resolution works in the following manner:

1. The workstation first checks the LMHOSTS cache and, if it finds the NetBIOS name, returns the IP address.
2. the workstation tries broadcasting to resolve the name (this works in the same manner as b-node resolution) and, if the destination system is active, it returns its IP address.
3. the workstation (if it is a Windows NT system) will check the LMHOSTS file in the \<winnt_root>\system32\drivers\etc directory

P-Node (or Point to Point Node) -  when using p-node name resolution, broadcasts are NOT used for name registration or name resolution. Instead, all systems register themselves with a NetBIOS Name Server (NBNS) upon start up. The NBNS is responsible for mapping computer names to IP addresses and making sure that no duplicate names are registered on the network. All systems must know the IP address of the NBNS, which is equivalent to a WINS Server. If the systems are not configured with the correct IP address for the NBNS, p-node name resolution will not work.  The p-node name resolution method uses directed User Datagram Protocol (UDP) datagrams and TCP sessions for its communication to and from the NBNS.  The main drawback of p-node name resolution is that if the NBNS cannot be accessed, there will be no way to resolve names and thus no way to access other systems on the network.

M-Node (or Mixed Node) -  uses a combination of b-node and p-node for name resolution. This method first uses b-node and then p-node, which in theory should increase local area network (LAN) performance. M-Node has the advantage over p-node in that if the NBNS is unavailable, systems on the local subnet can still be accessed through b-node resolution.  M-node is typically not the best choice for larger networks because it uses b-node and thus results in broadcasts. However, when you have a large network that consists of smaller subnetworks connected via slow Wide Area Network (WAN) links, M-node is a preferred method since it will reduce the amount of communication across the slow links.

H-Node (or Hybrid node) -  like m node, also uses both b-node and p-node, however it only uses b-node as a last resort. When configured to use h-node, a system will always first try to use p-node and then use b-node ONLY if p-node fails. In addition, a system can be configured to use the LMHOSTS file after p-node fails and before trying b-node.  H-node resolution does not require successful p-node registration for a system to initialize, however the system will use strictly b-node until p-node registration succeeds. If the NBNS is unavailable and the system resorts to using b-node resolution, it will continue to attempt to contact the NBNS so that it can return to using p-node if the NBNS becomes available.

NETBIOS (Network Basic I/O System)

Windows networking uses NetBIOS name resolution, which can be done by broadcasts (on a peer-to-peer network) or by a WINS server (on a client/server network). NetBIOS broadcasts can't cross routers, hence the need for a WINS server on a multi-subnet network.  If a station releases it's name, it sends out a broadcast on the local subnet, notifying all stations that the name no longer exists.

NOTE:  even with a WINS server, each workstation muct be configured as a WINS client !!  You must point them to the WINS server.  However, it is possible to leave some stations as non-WINS and they can be accessible from other subnets.  To do this, their names must be added as static entries to the WINS database or in the LMHOSTS file(s) on the remote system(s).

Netbios is a layer 2 (non-routable) protocol used for single-segment LAN's.  Since it is non-routable it will not go across 2 or more subnets, unless encapsulated in a layer 3 protocol such as IP.

NetBT normally uses one of the 4 node types - but it can also use WINS, the LMHOSTS files, or DNS for name resolution, depending on how TCP/IP is configured on a particular computer.

Since the name of each computer is just one entry, Netbios is a flat naming scheme, and therefore only works with a single LAN segment, or directly bridged (not routed) segments.  Hierarchical naming schemes are required to route across networks or subnets - they exist for TCP/IP using DNS, and also for a type of NetBIOS called NetBIOS Scope..

Windows NT networking components rely on a naming convention known as NetBIOS. In general, NetBIOS computer names consist of a single part (such as "Dad").  In contrast, TCP/IP components rely on a naming convention know as the Domain Name System (DNS). DNS computer names consist of two parts: a host name and a domain name, which combined form the fully qualified domain name (FQDN).  Fortunately, NetBIOS computer names are compatible with DNS host names, making interoperation possible between the two. Windows NT combines the NetBIOS computer name with the DNS domain name to form the FQDN. Under Windows NT, the DNS host name defaults to the same name as the NetBIOS computer name. You can change this if you need separate names.

Storing the Names

The first implementations of name spaces — both flat and hierarchical — relied on text files for mapping of computer name to IP address. Each computer on the internetwork had its name and IP address on a line in the file, and a copy of the file existed on each computer. This solution worked well for simple networks having relatively few interconnected computers. As networks grew in size and complexity, this method ran into scaling problems similar to those experienced with a flat name space.

Newer implementations have largely done away with the need for a mapping file on each machine; instead, server-based repositories store the necessary information. Mapping files still exist but are typically used in simple networks or as a safety feature in case the name servers are down.

The mapping files are

• HOSTS for DNS names (sample Win98 Hosts file)
• LMHOSTS for NetBIOS names (sample WinXP LMHOSTS file)

Note for example, when you install Windows NT, example HOSTS and LMHOSTS files are placed in the \systemroot\System32\Drivers\Etc directory.

LMHOSTS

*** see also Using LMHOST Files    LMHOSTS in Win2000

Here is a sample WinXP LMHOSTS file and a sample Win98 Hosts file

SMB

SMB is Server Message Block (SMB) protocol, also called the Session Message Block, NetBIOS or LanManager protocol.  The SMB protocol is used by Microsoft Windows 3.11, NT and 95/98 to share disks and printers

WINS (Windows Internet Naming Service)

*** see also the WINS FAQ

WINS is Microsoft's Windows legacy Internet Naming Service. A WINS server on your network does two things:

1. registers NetBIOS names from other workstations and servers on your network

2. resolves them to IP addresses. 

NOTE1:  even with a WINS server, each workstation muct be configured as a WINS client !!  You must point them to the WINS server.  However, it is possible to leave some stations as non-WINS and they can be accessible from other subnets.  To do this, their names must be added as static entries to the WINS database or in the LMHOSTS file(s) on the remote system(s).

NOTE2:  Wins was supposed to be replaced in Windows 2000-XP by the Active Directory and its global catalog, but support has been included for legacy applications and services that rely on WINS.

Name Registration - the computer registers its name by:

1. if there is a WINS server configured - it queries the WINS server
2. if no WINS server, the client sends name registration request packets (as broadcast messages) to the local subnet. To find a particular computer, the non-WINS computer sends name query request packets (as broadcast messages) on the local subnet. (This broadcast message cannot be passed on through IP routers.) 
3. if local name resolution fails, the local LMHOSTS file is consulted. These processes are followed whether the computer is a network server, a workstation, or other device

Name Resolution (resolved the IP address from the name) - similar to h-node but with a few differences:

1. Check to see if it is the local machine name.
2. Check its cache of remote names. Any name that is resolved is placed in a cache where it will remain for 10 minutes.
3. Try the WINS Server.
4. Try broadcasting.
5. Check the LMHOSTS file (if the system is configured to use the LMHOSTS file)
6. Try the HOSTS file and then a DNS, if so configured.

When you must have WINS - if there are subnets, with Netbios alone the PC's will never be able to see into the other subnet since NetBIOS isn't routable (unless you specifically setup the router to allow broadcasting into the other subnets).  Instead, you can use a WINS server on both sides of your router, or set up LMHOST files everywhere.

If you configure a single WINS server in your Domain and all the particpating systems point to the WINS server, the local subnet's Browse Master will retrieve the browse list from the Domain Master Browser (WINS Server) and systems on subnets other than the WINS server will be able to "see" all other systems in the Domain.

DNS (Domain Name System)

*** see also Microsoft's DNS Center    Ask Mr. DNS    

DNS was developed to solve the problems that arose when the number of hosts on the Internet grew dramatically in the early 1980s. DNS specifications are defined in RFCs 1034 and 1035. Although DNS might seem similar to WINS, there is a major difference: WINS is fully dynamic, whereas DNS requires static configuration for computer name-to-IP address mapping.

The Domain Name System (DNS) is a distributed database providing a hierarchical naming system for identifying hosts on the Internet. DNS was developed to solve the problems that arose when the number of hosts on the Internet grew dramatically in the early 1980s. DNS specifications are defined in RFCs 1034 and 1035. Although DNS might seem similar to WINS, there is a major difference: WINS is fully dynamic, whereas DNS requires static configuration for computer name-to-IP address mapping.

The Domain Name Space

The DNS database is a tree structure called the domain name space. Each domain (node in the tree structure) is named and can contain subdomains. The domain name identifies the domain's position in the database in relation to its parent domain. A period (.) separates each part of the names for the network nodes of the DNS domain. For example, the DNS domain name csu.edu, specifies the csu subdomain whose parent is the edu domain; csu.com specifies the csu subdomain whose parent is the com domain. Figure 32.4 illustrates the parent-child relationships of DNS domains.

Figure 32.4 A Portion of the DNS Database

As shown in Figure 32.4, the root node of the DNS database is unnamed (null). It is referenced in DNS names with a trailing period (.). For example, in the name: "research.widgets.com.", it is the period after com that denotes the DNS root node.

Top-Level Domains

The root and top-level domains of the DNS database are managed by the InterNIC. The top-level domain names are divided into three main areas:

• Organizational domains (3-character names)
• Geographical domains (2-character country codes found in ISO 3166)
• The in-addr.arpa. domain (a special domain used for address-to-name mappings)

Organizational domain names were originally used in the United States, but as the Internet began to grow internationally, it became obvious that an organizational division was inadequate for a global entity. Geographical domain names were then introduced. Even though a .us country domain exists, domain names in the United States are still predominantly organizational. As shown in Table 32.3, there are currently seven organizational domains.

Delegation

Responsibility for managing the DNS name space below the top level is delegated to other organizations by the InterNIC. These organizations further subdivide the name space and delegate responsibility down. This decentralized administrative model allows DNS to be autonomously managed at the levels that make the most sense for each organization involved.

Zones

The administrative unit for DNS is the zone. A zone is a subtree of the DNS database that is administered as a single separate entity. It can consist of a single domain or a domain with subdomains. The lower-level subdomains of a zone can also be split into separate zone(s). Figure 32.5 illustrates the relationship between DNS domains and zones.

DNS Zones

Fully Qualified Domain Names

With the exception of the root, each node in the DNS database has a name (label) of up to 63 characters. Each subdomain must have a unique name within its parent domain. This ensures name uniqueness throughout the DNS name space. DNS domain names are formed by following the path from the bottom of the DNS tree to the root. The node names are concatenated, and a period (.) separates each part. Such names are known as fully qualified domain names (FQDN). Here's an example of one:

mrp2.widgets.mfg.universal.co.uk.


Note In practice, most DNS host entries appear no lower than the fifth level of the DNS tree, with three or four being more typical.

Name Resolution

The key task for DNS is to present friendly names for users and then resolve those names to IP addresses, as required by the internetwork. Name resolution is provided through DNS by the name servers, which interpret the information in a FQDN to find its specific address. As illustrated in Figure 32.6, the process begins when a resolver passes a query to its local name server. If the local name server does not have the data requested in the query, it queries other name servers on behalf of the resolver. In the worst-case scenario, the local name server starts at the top of the DNS tree with one of the root name servers and works its way down until the requested data is found.

DNS Name Resolution

DNS name resolution consists of three key concepts: recursion, iteration, and caching.

• Recursion

  A resolver typically passes a recursive resolution request to its local name server. A recursive resolution request tells the name server that the resolver expects a complete answer to the query, not just a pointer to another name server. Recursive resolution effectively puts the workload onto the name server and allows the resolver to be small and simple.

• Iteration

  If the local name server cannot fully resolve the query, it enlists the aid of other DNS name servers throughout the DNS name space. A well-behaved local name server keeps the burden of processing on itself and passes only iterative resolution requests to other name servers. An iterative resolution request tells the name server that the requester expects the best answer the name server can provide without help from others. If the name server has the requested data, it returns it; otherwise it returns pointers to name servers that are more likely to have the answer. However, if a primary master name server is unable to resolve a request for data that should be in its zone, it returns an error to the requester.

• Caching

  As local name servers process recursive requests, they discover a lot of information about the DNS domain name space. To speed the performance of DNS and ease the burden on both the internetwork and the other name servers, local name servers temporarily keep this information in a local cache. Whenever a resolver request arrives, the local name server checks both its static information and the cache for an answer. Even if the answer is not cached, the identity of the name server for the zone might be, which reduces the number of iterative requests the name server has to process.

Testing the Network Redirector

Step 1)  Test the network redirector by changing the computer name to the name of the computer to which you are trying to connect. To do so, follow these steps: 

1. Click Start, point to Settings, and then click Control Panel. 

2. Double-click Network. 

3. Click the Identification tab, and then type the name of the computer to which you are trying to connect in the Computer Name box. 

4. Click OK, and then click Yes when you are prompted to restart your computer. 

You should receive the following error message when your computer is starting: 

"The following error occurred while loading protocol number 1. Error 38:The computer name you specified is already in use on the network. To specify a different name, double-click the Network icon in Control Panel"

Using the Client for Microsoft Networks displays the following error message report : 

"The following error occurred while loading protocol number 0. Error 38: The computer name you specified is already in use on the network. To specify a different name, double-click the Network icon in Control Panel. would instead indicate that Win9x Computer Name is identical to a user name account, so a very simple solution to this is to differentiate Computer Name from known user name accounts."

If you receive the error message, the two computers are communicating. 

If you do not receive the error message, one of the following hardware problems may exist: 

	The network adapter's configuration (hardware, I/O address, IRQ, memory conflict, etc) is incorrect on one or more of the computers. For information about how to change network adapter settings, refer to step 3.
	One or more of the network adapters is malfunctioning. If your network adapter includes a diagnostic utility, run the utility to determine if the network adapter is functioning properly.
	There is a problem with the cabling or connectors. This could be an electrical short, interference, or a cable, connector, or terminator that is not the correct specification for your network.

Step 2)  To troubleshoot electrical shorts and interference problems, either test the cabling with a testing device, or replace it with
cables and connectors that are known to work correctly.  Then repeat the steps, changing the computer name back to its original, unique name. 

Step 3)  Remove and reinstall the network adapter drivers. To do so, follow these steps: 

1. Click Start, point to Settings, and then click Control Panel. 

2. Double-click Network. 

3. In the list of installed network components, click your network adapter, click Remove, click Client For Microsoft Networks, and
   then click Remove. 

4. Click OK, and then click Yes when you are prompted to restart your computer. 

5. Repeat steps 1-2

6. On the Configuration tab, click Add. 

7. Click Adapter, and then click Add. 

8. In the Manufactures box, click the network adapter's manufacturer, and then click the appropriate model in the Network
   Adapters box. 

Click OK, click OK again, and then click Yes when you are prompted to restart your computer. 

NOTE: If the network adapter is hardware configurable (uses jumpers or switches), the settings on the network adapter and in Device Manager must match. To determine the settings for the network adapter, refer to the documentation included with the adapter or contact the network adapter's manufacturer. 

If the network adapter is software configurable, you may need to specify a different IRQ, DMA channel, I/O address, or RAM address in Device Manager. For example, some hard disk controllers are configured to use an I/O address of 300h by default, which is also the default for some network adapters. To change the network adapter's resource settings in Device Manager, refer to step 3. 

NET Diag (Win95-98)

Windows 98/95 includes the NET DIAG utility, which can be used to perform a low-level communications test between two computers - seems to only work with IPX. To perform this test, follow these steps: 

NOTE : Both computers must have the same protocols installed in order for this test to work. 

On one computer, click Start, point to Programs, and then click MS- DOS Prompt.  

At the command prompt, type "net diag" (without quotation marks) and press ENTER.  NET DIAG searches for a diagnostics server and should display the following prompt:

"No diagnostic servers were found on the network. Is Microsoft Network Diagnostics currently running on any other computers on the network?" 
Press N (for No). This causes the computer from which you are running NET DIAG to be a diagnostic server until you press a key.   

On the other computer, click Start, point to Programs, and then click MS-DOS Prompt. 

At the command prompt, type "net diag" (without quotation marks) and press ENTER. 

If a NetBIOS-capable protocol (such as NetBEUI or TCP/IP) and IPX/SPX are both installed, you receive the following prompt: 

"IPX and NetBIOS have been detected. Press I to use IPX for diagnostics, N to use NetBIOS, or E to exit this program."

Press I (for IPX) or N (for NetBIOS) to test the network connection using that particular protocol. 

If you are unable to communicate with the diagnostic server using the protocol you chose, try the other protocol. 

If you are able to communicate with the diagnostic server using one protocol but not the other, the network is working properly. For the protocol you are unable to communicate with, verify that it is installed correctly on both computers, and then run NET DIAG again. 

If you are unable to communicate with the diagnostic server using either protocol, run NET DIAG again, but this time reverse the role of each computer.