NetBIOS-Over-TCP/IP Name Resolution Services
Microsoft Windows95 and Windows NT both provide a set of lightweight, simplistic networking services, allowing users to share and use one anothers' resources easily. There's no need for a dedicated file server, centralized security or any other advanced networking technologies.
These systems are just two members of a rather large family that also includes Microsoft Windows for Workgroups, Microsoft LAN Manager for OS/2, IBM LAN Server, Digital Equipment Corp.'s PathWorks for VMS, a variety of freeware ports of SAMBA, and LAN Manager for Unix (available from Hewlett-Packard Co., NCR Corp., The Santa Cruz Operation and others). Even Novell has an offering that enables NetWare servers to interact with these LAN Manager-based workgroup products.
The core technologies that tie together these systems are Server Message Blocks (SMBs) and NetBIOS-over-TCP/IP (NBT). The SMB protocols performing the file- and printer-sharing dirty work are invisible to end users, since the networking drivers handle the intersystem communications. However, NBT is visible to end users, mostly because it doesn't work well in non-local, non-broadcast environments. Accessing and utilizing remote networks and systems can be extremely frustrating if the appropriate steps aren't taken first. We'll be examining the various options users have in implementing NBT services on their LANs.
Why NetBIOS Can't Scale
Several years ago, IBM developed NetBIOS with the goal of drawing up a network protocol that would work on small networks of PCs. The keyword in that sentence is "small." At the time, the practical limit for an Ethernet segment was 30 nodes, while IBM's Token-Ring was limited to 255 nodes. The design goal was to build a small and fast protocol that would allow for human-assigned names of devices, such as "MyComputer," that are easier to remember than a complex numbering scheme such as TCP/IP's system.
The assumption was that there were only a few nodes on the network and that devices would be appearing and disappearing at random (as PCs are apt to do). Therefore, it was best to be able to locate a device with a broadcast rather than with any sort of centralized registry or a distributed directory service. NetBIOS was designed to use broadcasts as the sole means of locating devices—and we have been stuck with this limitation to this day.
When a node needs to communicate with another node, it broadcasts to find the remote system. The remote system is responsible for responding to the broadcast with a direct unicast response. Once two nodes have located each other, they can communicate directly using targeted unicast packets. Unfortunately, this design breaks down quickly in even minor complex networks, and is completely nonscalable.
Broadcast packets don't work in today's router-based networks, because the routers don't pass packets that are not specifically destined for another network node. The only way to make NetBIOS work in large networks is to bridge the various segments into a large virtual network, or to explicitly forward NetBIOS broadcasts across all bridges and routers.
But because NetBIOS nodes broadcast so much and too many nodes can saturate a network, large bridged networks don't work very well.
In order for NetBIOS-based applications to run over TCP/IP networks, the NetBIOS application must see names and the IP protocol must see numbers, but neither can see the other. A layer between the two must map NetBIOS names to IP addresses and convert IP addresses back to NetBIOS names. This layer is known as NetBIOS-over-TCP/IP (NBT) and is documented in Request For Comment (RFC) 1001 and 1002. See "Sharing Files Over The Internet With Windows95" on page 116 in our August 15 issue for some implementation assistance with NBT in Windows95.
There are three types of NetBIOS nodes defined in these two RFCs. A b-node (broadcast node) uses broadcasting to query nodes on the network for the owner of a NetBIOS name. A p-node (point-to-point node) uses directed calls to communicate with a known NetBIOS name server, such as a Windows Internet Name Service (WINS) server, for the IP address of a NetBIOS machine name. An m-node is a mixed node that uses broadcasted queries to find a node, and failing that, queries a known p-node name server for the address.
Another node type under review is an h-node, which reverses the m-node standard so that a directed query is executed first, and failing that, a broadcast is attempted. The h-node model is the default used by Microsoft's networking clients whenever a WINS server has been selected in the client configuration.
Remember that the node types apply only when a node is attempting to match an IP address to a NetBIOS node name. Once the device has discovered the IP address of the machine it's trying to communicate with, it no longer broadcasts information, but sends the IP traffic directly to the node associated with the NetBIOS name.
NetBIOS Name-to-IP Address Resolution Schemes
NBT can use a variety of mechanisms for name resolution. The simplest conceptual and practical method is to use broadcasts to locate network resources. This calls for the node to issue TCP/IP broadcasts for every NetBIOS query. This method works only if the other system is on your local network, and will see and respond to the broadcast.
Another way to resolve the name is to preload the NBT client's name-to-address resolution cache with an IP address. This way, no broadcasts will be needed, since the IP-address mapping will be in memory. You also can create a text file called LMHOSTS that is similar in function to the HOSTS files used by most TCP/IP stacks.
Another option is to use WINS servers, which are essentially p-nodes as described in RFCs 1001 and 1002. You also can use your Domain Naming Service (DNS) servers as name servers, though this method is somewhat limited in functionality.
NBT name resolution occurs by recursively searching through these various mechanisms until a name match is found. The default order used by Microsoft's networking clients—assuming that each of these mechanisms is enabled—is as follows: NBT searches its internal name cache; NBT queries the WINS server(s) defined; a broadcast is issued; NBT searches the LMHOSTS file; and, finally, NBT issues a DNS query for the NetBIOS name in question.
If no match is found, a name-not-found error is returned to the NetBIOS application. For the best performance, you should configure your clients so that the most-often used NetBIOS names are preloaded into the client cache. Be aware, however, that the client-name cache is fairly small, so names in the cache often will get purged if your clients connect to multiple servers, or if there is a lot of network browsing. This will result in the cache being emptied, and broadcasting and WINS querying being used anyway. The cache size values can be increased, but the available client memory will decrease as a result. This is perhaps the biggest limitation resulting from NetBIOS' small-network design objective.
The LMHOSTS Database
The LMHOSTS database is a raw text file whose format is functionally identical to the TCP/IP HOSTS file. It contains a numerical IP address, a tab character and a NetBIOS name (and optionally, a comment). Do not confuse the LMHOSTS database with the HOSTS database. Although they are similar in use and structure, they serve two entirely separate purposes.
Simply put, the LMHOSTS file allows NBT to take advantage of both the broadcasting and point-to-point architectures without requiring a dedicated name server on your LAN. Realizing that the "LM" in "LMHOSTS" stands for "LAN Manager" may make the clarification easier.
A sample entry in the LMHOSTS file might look like the following:
198.105.232.1 FTP # Microsoft's Public FTP server.
This line simply tells NBT that any NetBIOS queries that are destined for the NetBIOS node FTP should go to 198.105.232.1.
You need to be careful about the entries you put into your LMHOSTS file. Some of the most common problems come from not providing the exact NetBIOS host name as the destination system sees it. For example, you cannot simply define the host name of FTP as FTPSERVER. The destination system will see the request as being for another NetBIOS host, and will ignore it.
You may also need to define NetBIOS service-name mappings, and not simply host-name mappings. Just as a workstation has a NetBIOS name, so do NetBIOS services, including common workgroup applications such as Lotus Notes, SNA gateways and others. Since NetBIOS doesn't use port numbers or sockets like IPX or TCP/IP, its flat and limited name space must be capable of supporting a variety of names for each destination system. For example, if you are running an SNA gateway, a licensing server and a client-server application on the same system, each of these services must have a distinctive NetBIOS name that indicates the service itself and not just the NetBIOS host name of the workstation. The destination service will not respond to the application request if the incoming name does not match the desired service name exactly.
An example of an application entry in the LMHOSTS file looks just like a workstation name. If you have multiple applications running on a single workstation, then you will need to have multiple entries in your LMHOSTS file.
Some vendors have gotten fairly creative over the years in assigning NetBIOS names to their services, making them case-sensitive, placing spaces in the name or adding non-printable extended characters. Although technically this is not a problem in the broadcast-centric nature of NetBIOS LANs of old, it becomes a difficulty with services running on remote servers.
To identify these names, you must enclose the entry in quotes. Also, if you have to use a hex character in the name, then you must preface the character with the tag \0x. Since NetBIOS names are limited to 15 characters, you must place the hex characters at the beginning of their extended name. An example of an odd service entry might look like the following:
127.1.1.1 "SNA Gateway1 \0x20" # trailing hex character.
The above example would put hex 20 in the 16th byte of the NetBIOS name "SNA Gateway1."
Preloading Entries Into the NBT Cache
Remember that the LMHOSTS file is consulted only if the NetBIOS name-to-IP-address mapping is not in memory, and after a NetBIOS broadcast has failed. By preloading the NetBIOS names into the client's NBT cache, you will cut down on your broadcast traffic considerably, as well as speed client operations since the NBT driver won't have to wait for NetBIOS broadcasts to time-out before searching the LMHOSTS file.
If you wish to add a frequently used name to the LMHOSTS file, you would use a tag, called #PRE, at the end of the name entry. Note that although the "#" symbol in the LMHOSTS file normally signifies a comment, NBT uses the #PRE string for backward compatibility with LAN Manager servers that do not support selective preloading. Older systems will ignore the #PRE command because they think it is a comment.
An example of a name-to-address entry that is to be preloaded into the NBT cache might look like the following: 198.105.232.1 FTP #PRE # Microsoft's FTP server. Note that everything after the last comment tag is ignored.
This entry would cause NBT to send a directed query directly to the FTP host whenever it was requested, and a broadcast would not be issued beforehand. This is because the #PRE tag is preloading the entry into the NBT cache at system startup.
Windows Internet Naming Service
Managing LMHOSTS files on the PCs scattered throughout your organization can be incredibly tough, if not impossible. For many sites, incorporating a NetBIOS name server is much more manageable, though the costs can be prohibitive. In essence, a WINS server is a p-node server as defined in RFCs 1001 and 1002. However, it is proprietary to Microsoft in implementation. Other systems (SAMBA, for example) also offer p-node servers, but are not completely interoperable with WINS servers.
WINS servers have NetBIOS name-to-IP address databases that are built automatically from a variety of sources: If you are using NT-based Dynamic Host Configuration Protocol (DHCP) servers, WINS can read the DHCP databases to find out the NetBIOS names and IP addresses registered. Also, WINS clients that come up on the network will automatically register their NetBIOS names and IP addresses with the WINS servers specified in their local or DHCP-provided configurations, rather than issue the name registration broadcasts, allowing remote systems to store their name-to-address mappings on a centralized server.
Additionally, you can configure WINS servers to exchange information with other WINS servers, allowing you to provide replicated maps of your local networks on a worldwide basis. However, there is a maximum of 100 such "peer" definitions in current WINS implementations, forcing you to restrict the number and type of relationships among the various servers in very complex networks.
WINS servers also store local NetBIOS broadcasts so that they can answer on behalf of other systems. This allows the WINS database to be used with legacy NetBIOS applications that do not support WINS directly. When a b-node advertises its presence on the network, any local WINS servers will store the information in their database and will respond to lookup queries from remote systems on behalf of the local device. Note that the WINS server(s) will only pick up on broadcasts issued on the network segments that it is physically attached to, since the legacy system does not know to forward the name and address pair to remote WINS servers.
You also can configure your PCs to be WINS "proxy" servers that will respond to broadcasts, though they cannot be used as formal p-node servers. When a local broadcast is issued by a non-WINS-enabled client, the WINS proxy server will issue a query to a predefined WINS server. The WINS proxy then stores the responses into its local NBT cache and responds to any subsequent requests for the NetBIOS node name. Since most clients issue multiple broadcasts, the WINS proxy can generally respond to the original query prior to the client's broadcast timing out. The entry is held in the cache until it expires or the cache space is needed for new entries. On desktop PCs, the cache tends to be small, so don't expect a lot of benefit if you have a busy network.
Using DNS Servers
Because of TCP/IP's 32-bit numerical addressing, it is a truly distributed network protocol capable of spanning huge distances and multiple network segments. Unfortunately, these numbers are hard to remember. This is why DNS was invented; it provides a hierarchical namespace that maps to IP addresses, allowing users to reference www.nwc.com instead of having to remember its IP address.
While Microsoft has gone off and developed WINS as a mechanism for building databases that map IP addresses to NetBIOS names, DNS has been around for years, and provides a much more robust mechanism that all applications can use, instead of just NetBIOS apps. However, the NetBIOS limitations of NBT still apply. The NetBIOS name you are querying for must match the name as registered by the system that owns it. Therefore, it is not possible for you to view the resources on the host ftp.microsoft.com by that name. You must instead refer to it by its NetBIOS name of FTP.
This severely limits the usefulness of DNS as a NetBIOS name-to-IP address mapping tool. However, it is still very useful for viewing nodes that are in the same TCP/IP domain name as your clients, allowing you to do away with LMHOSTS files and WINS servers for name resolution.
Windows NT 4.0's networking client has an enhanced DNS name-resolution capability that will allow you to query for devices by their fully qualified domain name, regardless of the domain that you are in. Using this technology, it is now possible to query for ftp.microsoft.com and to view its network resources. This capability also should be incorporated in future releases of other Windows code bases as well, making the difficulties we face with current implementations of Windows for Workgroups, Windows NT, LAN Manager and Windows95 irrelevant.
Summary
NetBIOS is extremely limited, but provides a lowest-common-denominator approach to multiprotocol networking. Its use of names for nodes and services makes it easy to use, and its lack of dependency on any formal hierarchical addressing mechanisms makes it flexible. You can put NetBIOS on top of just about any protocol, from IPX to DECnet to TCP/IP, and it will work.
However, all sorts of problems arise when you try to map a flat, nonhierarchical name space onto a distributed, hierarchical address space. There are several options available to the user however, so it is possible to build a name table that meets just about any requirement. Also, Microsoft has resolved many of the difficulties with the new technology in NT 4.0, though these advancements are only useful to NT 4.0 clients attached to NT 4.0 servers.
Copyright © 2010-2017 Eric A. Hall.
Portions copyright © 1996 CMP Media, Inc. Used with permission.