Community Articles

Where You Connect Depends on Where the WINS Blow You

Mike Pennacchi

Windows 2000 came out with the promise that we could dump WINS and move to DNS. Not a bad idea considering that WINS is a flat naming structure that limits you to 15 characters. However, as with all changes in technology, we can’t throw away our existing systems until we replace them with new ones. Depending on your capital budgets, you may not see the end of WINS before the end of your computing career.

Recently, we were working on an application problem. The person using the application said that it was slow. As in most cases where there is a slow application, the network was blamed for the problem. In an effort to restore the network to its good name and to find out exactly why the application was slow, we began analyzing the application.

While going through the traces, one of the local network administrators commented that the client PC was connecting to the wrong interface on the server. I asked how many interfaces the server had and which one the client should be using. The local administrator explained that the server had two interfaces. One was used for production traffic and one was used for backups, a configuration we have seen many times. The client PC should be connecting to the production interface and only the backup server should be using the backup interface, he explained.

As with any network analysis, we must look at how the client PC learns about things, so we can determine why it is making the decisions that it is. In this case, the client starts with a NetBIOS name. Depending on the type of service that the client is trying to access, it will append a hex character onto the end of the name. This is known as the 16th character suffix and is used to qualify the name during registration and queries.

This query is then sent to the WINS server. The server will look up the name in its database and respond to the client PC. In some cases, such as the one we were analyzing above, the client has multiple network interface cards. These devices are known as multi-homed devices. Since WINS does not know which of these interfaces you want to use, it will register one NetBIOS name with two IP addresses.

Each time a query is sent to WINS for that NetBIOS name, the server will reply with both IP addresses. The client must then make a decision about which of these IP addresses to use. The following is an excerpt from Microsoft’s website detailing this decision process:

  • Excerpt from Microsoft Knowledgebase Article Q161425

NetBT uses the following algorithm for selecting an address from the list returned by WINS:

  1. Check for addresses on local subnets or networks:
    • If one or more of the addresses in the name query response list are on the same logical subnet as the calling binding of NetBT on the local computer, these addresses are put into a sublist of addresses.
    • If no addresses were found in step 1a, and then if one or more of the addresses in the list are on the same logical subnet as any binding of NetBT on the local computer, those addresses are put into a sublist.
    • If no addresses were found in steps 1a or 1b, and then if one or more addresses in the list are on the same logical network as any binding of NetBT on the local computer, those addresses are put into a sublist.
  2. Randomize the lists:
    • If a sublist was generated in step 1, that list is put in a random order and the remaining addresses in the name query response list are added to the end of that list, also in a random order.
    • If no sublist was generated in step 1, the main list is sorted in a random order.
  3. Picking the address:
    • The client will take the new randomized list and ping the first address on that list; if the server responds to the ping, that address will be used.
    • If pinging the first address fails, the next address in the list will be pinged until a good address is found.

Below is an example of the WINS query and the response from the WINS server:

Query –

WINS: ----- WINS Name Service header -----

WINS:
WINS: ID = 32818
WINS: Flags = 01
WINS: 0... .... = Command
WINS: .000 0... = Query
WINS: .... ..0. = Not truncated
WINS: .... ...1 = Recursion desired
WINS: Flags = 0X
WINS: ...0 .... = Non Verified data NOT acceptable
WINS: Question count = 1, Answer count = 0
WINS: Authority count = 0, Additional record count = 0
WINS:
WINS: Question section:
WINS: Name = GOWSUCOUGS<20><20 />20
WINS: Type = NetBIOS name service (WINS) (NetBIOS name,32)
WINS: Class = Internet (IN,1)
WINS:

Response –

WINS: ----- WINS Name Service header -----

WINS:
WINS: ID = 32818
WINS: Flags = 85
WINS: 1... .... = Response
WINS: .... .1.. = Authoritative answer
WINS: .000 0... = Query
WINS: .... ..0. = Not truncated
WINS: Flags = 8X
WINS: ..0. .... = Data NOT verified
WINS: 1... .... = Recursion available
WINS: Response code = OK (0)
WINS: ...0 .... = Unicast packet
WINS: Question count = 0, Answer count = 1
WINS: Authority count = 0, Additional record count = 0
WINS:
WINS: Answer section:
WINS: Name = GOWSUCOUGS<20><20 />20
WINS: Type = NetBIOS name service (WINS) (NetBIOS name,32)
WINS: Class = Internet (IN,1)
WINS: Time-to-live = 0 (seconds)
WINS: Length = 12
WINS: Node flags = 60
WINS: 0... .... = Unique NetBIOS name
WINS: .11. .... = H-type node
WINS: Node address = [192.168.20.35], GOWSUCOUGS
WINS: Node flags = 60
WINS: 0... .... = Unique NetBIOS name
WINS: .11. .... = H-type node
WINS: Node address = [192.168.23.35], GOWSUCOUGS
WINS:

The WINS server gives us two IP addresses for the same NetBIOS name. In this case, the client PC was not on the same subnet as either of these IP addresses. Based on the client decision rules, the client will select one of these addresses at random. I get very nervous when devices on my network start selecting things at random. When architecting a network we want to ensure that things are operating exactly as we would expect them to, not randomly.

After the WINS response is received, we see that the client then pings the first server selected:

Dest Source Description

ORTON STEVENS WINS C ID=32814 OP=QUERY NAME=GOWSUCOUGS<20><20 />20
STEVENS ORTON WINS R ID=32814 OP=QUERY STAT=OK
GOWSUCOUGS STEVENS ICMP Echo
STEVENS GOWSUCOUGS ICMP Echo reply

So, how do we fix this? On NT devices, the WINS client can be unbound from those interfaces that should not be put into the WINS database. If the backup server is referring to the server to be backed up by IP address or DNS name, it is not necessary to have that interface on the server to be backed up in the WINS database. If the multi-homed device is a Windows 2000 computer, NetBIOS over TCP/IP can be disabled under the WINS tab for Advanced TCP/IP settings.

As with any change to a networking device, a trace should be taken before and after the change is made. If the multi-homed device is registering multiple IP addresses, you will see this in the WINS name registration packets sent during boot-up. After you change the Bindings or the WINS settings, you should see only those IP addresses registered that you want to have registered. If your backup system depends on WINS to resolve the IP address of the servers to be backed up, you may have to resort to static WINS entries, cough, choke, gag...


sitemap | legal | request info | contact

 

NetQoS - Network Performance Management products and services for the world's largest networks. © 2001-2008 NetQoS, Inc. All rights reserved.