Resolving NetBIOS Names Using Broadcasts
Broadcasting was the earliest method used by Microsoft to resolve names into IP addresses. Resolving names by broadcasting is like getting help from a neighbor in a small town. You lean your head out a screen door and yell, "John Henry, when y'all get a second, come on over here and give me a hand. Y'hear?"
For this kind of broadcast-based name calling to work, though, there can be only one John Henry in town. And when a Windows computer broadcasts for a computer named SRV1, there should only be one server on the wire with that name. For this reason, Windows computers also use broadcasts to register their names. This ensures uniqueness. Broadcast registration works as described in Procedure 4.1.
Procedure 4.1 Functional Sequence for NetBIOS Name Resolution Using Broadcasts
When a Windows computer named PRO1 is booted and comes onto the network, it first checks to make sure that no other computer is using its name. It does this by sending out a NetBIOS Name Registration broadcast. This application layer broadcast is placed into an IP multicast packet at the Network layer and directed at the client's subnet.
For example, a client with the IP address 10.1.3.150, subnet 255.255.0.0, would send out a name registration multicast addressed to 10.1.255.255. Stations that are in the multicast space but not in network 10.1.0.0 ignore the multicast.
If another computer with the name PRO1 hears the multicast, it sends back a challenge saying, in effect, "Back off. I'm using that name, and here's my IP address to prove it."
The newcomer doesn't meekly retreat in the face of this challenge, however. It verifies the identity of the challenger by sending out an ARP broadcast containing the challenger's IP address. If the ARP gets no response, the newcomer uses the name anyway. If the ARP gets a response, the newcomer gives up, refuses to bind network services to the adapter, and informs the user of the duplicate name. It also puts a warning in the Event log.
If the newcomer is satisfied that its name is unique, it binds the application layer protocols such as Workstation, Server, and Browser to the TCP/IP stack and initializes the network drivers.
When the network applications can see the network, the SMB redirector—LanMan Workstation in the case of Windows Server 2003—prepares to communicate with a server—call it SRV1. LanMan Workstation builds an SMB message destined for SRV1 and sends it to the Tcpip.sys driver.
When Tcpip.sys gets the SMB message, it uses Netbt.sys to send out a NetBIOS Name Resolution multicast looking for the IP address of the destination server. Netbt.sys sends out the multicast every half-second for three tries and then gives up if it does not get a response.
If SRV1 hears the multicast, it responds with an acknowledgement that contains its IP address. The acknowledgement is sent directly back to the client because SRV1 learned the client's NetBIOS name, IP address, and MAC address from the name resolution multicast.
Tcpip.sys nabs the IP address from the name resolution response and sends out an ARP to confirm the address. When it is confirmed, Netbt.sys caches the name and IP address of the server in a NetBIOS name table where it can be used in subsequent transactions.
This small-town method of shouting out names and waiting for responses doesn't work very well in the bright lights and big city of a routed TCP/IP network, where routers and Layer 3 switches and intelligent bridges are configured to stop broadcasts and multicasts. The next two topics cover how to use Lmhosts and WINS to handle name resolution and registration in a routed environment.