How NetBIOS names work
NetBIOS names are located through a series of steps that begins with checking the local cache. You then check an LMHosts file and, lastly, progress into a broadcast message that looks for the name (that is, unless the default actions have been changed). Before you begin, you need to understand the four kinds of resolution that NetBIOS does natively.
First resolution
The first resolution mechanism is not really a resolution mechanism at all. It is an internal cache that is in each Windows machine. This cache is populated by previous name resolution attempts and by a special option in the LMHosts file (described next). The idea behind the cache is that, if the software needed to resolve the name once, it is quite likely that it will soon need to do so again. If you need to resolve the name again, the name is cached in order to improve responsiveness and limit network traffic. In order to reduce the possibility that the cache will become invalid because too much time has passed since the name was resolved, the cache has a limited lifetime, typically 10 minutes. However, entries put into cache by the LMHosts file option never expire. It is also important to have a limited lifetime for the cache to minimize the amount of memory used for caching. Although in today’s world of 512-MB desktop computers this may seem odd, it was a real concern when the NetBIOS naming strategy was developed and we were still dealing with conventional (640K) memory.
Second resolution
The second resolution method is where the LMHosts file is consulted to see if there are any NetBIOS names that match the NetBIOS name being queried. In its simplest form, the LMHosts file contains an IP address and a host name. In addition to the IP address and NetBIOS name, you have two more options. The first option is #PRE, which causes the entry to be cached into memory. This has little effect in today’s environment. The second option, #DOM (domain), is used to associate the computer with a NetBIOS domain name. This can be helpful if you are trying to find a domain controller to log into. The LMHosts file is located in %SYSTEMROOT%\SYSTEM32\DRIVERS\ETC. Typically, %SYSTEMROOT% is the C:\WINNT directory.
Third resolution
The third resolution mechanism used by the local computer to resolve the NetBIOS name involves consulting one or more naming servers. In most cases, the naming server contacted is a Windows Internet Naming Server (WINS). Technically, you could create a NetBIOS naming server that is not a WINS server, but it is rarely done. The NetBIOS naming server standard is an open standard controlled by RFC 1001 and RFC 1002. Each computer contacts the WINS server upon startup and provides the computer’s IP address, as well as its name. It stores this information into a database that may be replicated with other WINS servers. The WINS server also verifies that the name is not already in use. The database maintained by the WINS server is queried each time a client computer asks it to resolve a NetBIOS name. The WINS server can either resolve a name or not. There is no delegation of authority with a WINS server. Multiple WINS servers can be listed in the client configuration for consultation. In this case, the last WINS server to respond will be consulted. It is assumed to be a copy of all of the other WINS servers listed in the client configuration. The client will cycle through the list of its WINS servers until it locates one that is responsive.
Fourth resolution
The fourth and final resolution method is to broadcast for the NetBIOS name. The computer broadcasts a special packet that is received and processed by all machines on the network. The packet then requests that the computer identify itself. This is effective within a local network but is ineffective across routers, which do not forward broadcast packets. This means that the broadcast NetBIOS name resolution method does not work across routers. It can only be used for computers within the same IP subnet. Another problem with broadcast resolution is that it takes time from every computer. Finally, broadcast resolution requires that the packet be transmitted to every computer on a subnet. This can effectively eliminate the usefulness of a switch, which is designed to prevent computers from seeing traffic that is not destined for them. Since a broadcast is by definition destined for every computer on the subnet, it must be broadcast to every computer. As the amount of broadcast traffic increases, the switches tend to behave more like hubs—passing on every packet to every connected computer. The tendency to broadcast is one of the reasons that NetBIOS is not well liked in networking circles.
While the preceding is the default order, the order itself can be controlled via a node type attribute. The node type controls the order of resolution for the computer and the types of resolution consulted. The node type can never prevent the local cache from being consulted first, nor can it prevent the LMHosts file from being consulted. It only controls the behavior of the resolving computer with regard to when it will broadcast and when it will use a WINS server.
The node type can be set to only three modes. The first mode, B-mode, only uses the cache, LMHosts and broadcast. It will not try to use the WINS server. The second mode, P-mode, never broadcasts. It only uses the cache, LMHosts file, and WINS server. The final mode, H mode, or hybrid mode, behaves as described above by checking the LMHosts file and the WINS server, and then broadcasting. Hybrid mode is the default mode for all Windows workstations that have not had another node type provided via configuration or via DHCP.
Comments | NOTHING