Delay in NetBIOS connections from a multi-homed computer

When you use a multi-homed computer to connect to another computer, and the multi-homed computer is running one of the versions of Microsoft Windows that is referred to in the "Applies to" section, there may be a delay in establishing the connection.

This problem occurs because, by default, the Windows redirector uses the following logic to establish a NetBIOS session:

• Try to connect to the destination name on all bound transports, in the order that they are bound.
• If IgnoreBindingOrder is set to 0, wait for the primary (first-bound) transport to finish. If it succeeds in reaching the destination, set up a session on that transport. Cancel the other connections.

Note In Microsoft Windows 2000 and later versions, the IgnoreBindingOrder registry entry does not exist. If this registry entry does not exist, the default value for IgnoreBindingOrder is 1 (TRUE). In Microsoft Windows NT 4.0, the default value for IgnoreBindingOrder is 0 (FALSE).

If your multi-homed computer is on two networks that are connected by a router, and if the computer that you want to connect to is on only one of those networks, there are two paths to the target system. If the connection succeeds on both paths, the redirector chooses the primary transport as the preferred path. For example, the redirector may choose the local source IP address that is associated with that binding of NetBIOS over TCP/IP (NetBT) as the preferred path. The redirector cancels the remaining connection. Because of this choice, the packets that are sent from the multi-homed computer may be internally routed to the directly connected subnet, and the packets that the target system sends in response traverse the router. This scenario can be confusing to troubleshoot.

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

A newer Windows redirector is available. You can configure this redirector to accept the first transport to complete a connection and immediately cancel the connections on the other transports. A newer version of NetBT that supports better handling of multiple calls and cancels is also available.

To take advantage of this improvement, you must add a registry parameter.

To configure the registry parameter to correct the issue that is referred to in this article, start Registry Editor, locate the appropriate subkey by using the information below, and then add the registry value.

Microsoft Windows NT 4.0

Use the following registry subkey and value:Note Setting this value to 1 (one) causes the redirector to accept the first transport to complete a connection instead of waiting for success or failure on the primary transport.

Microsoft Windows Server 2003, Microsoft Windows XP, and Microsoft Windows 2000

Use the following registry subkey and value:

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

TCP Connections to and from Multi-homed Computers

If the connection is a NetBIOS-based connection that uses the redirector, little routing information is available at the application level. The NetBIOS interface supports connections over various protocols and has no knowledge of IP. Instead, the redirector places calls on all the transports that are bound to it. If there are two interfaces in the computer and one protocol is installed, there are two transports that are available to the redirector. Calls are placed on both transports. NetBT submits connection requests to the stack by using an IP address from each interface. Both calls may succeed. If so, the redirector cancels one of them. The choice of which one to cancel depends upon the redirector IgnoreBindingOrder registry value. If the registry value is 0, the primary transport, which is determined by binding order, is the preferred one. The redirector waits for the primary transport to time out before accepting the connection on the secondary transport. If this value is 1, the binding order is ignored. The redirector accepts the first connection that succeeds and cancels the others.

Note Microsoft TechNet documentation references the wrong registry subkey (ObeyBindingOrder) on the following Microsoft Web site: This problem does not apply to Windows Sockets-based connections such as Web browsers make. This behavior only occurs on NetBIOS over TCP/IP sessions such as file and print sharing. When a Windows Sockets program makes a connection from a multi-homed host, the best local source address is automatically selected by using the route table. This selection occurs unless the program is specifically set to select a local IP address to use in the bind() call.

For more information about how to select an outbound network adapter, click the following article number to view the article in the Microsoft Knowledge Base: