Connecting to Network Resources from Multihomed Computer

 Last reviewed: August 14, 1997
Article ID: Q166159
The information in this article applies to:
  • Microsoft Windows NT Workstation version 4.0
  • Microsoft Windows NT Server version 4.0

SYMPTOMS

When you connect from a multihomed computer running Windows NT to another computer, the local source IP address used may not be optimal. If the multihomed system is attached to two different (disjoint) networks, and the target system is on only one of the networks, there may be a delay in establishing the connection.

This behavior only occurs on NetBIOS over TCP/IP sessions; therefore, this information does not apply to Windows Sockets applications such as Web browsers.

CAUSE

The Windows NT 4.0 (and earlier) redirector used the following logic to establish a NetBIOS session:

  • Place a call to the destination name on all bound transports, in the order they are bound.
  • Wait for the "primary" (first-bound) transport to complete, and if it was successful in reaching the target, set up a session on it and disconnect (cancel) the other calls.

In the case of a computer that is multihomed on two connected (by a router) networks, if the target system is on only one of those networks, there are two paths to the target system. In this case, the call succeeds on both paths, and the "primary" transport (for example, the local source IP address associated with that binding of NetBT) is the chosen one. The other call is cancelled. This means that the less optimal path (through the router) may win out over the more optimal (direct) path. In this case, packets sent from the multihomed computer are internally routed to the directly connected subnet (because the route table shows a direct route to it), but packets sent in response from the target system traverse the router. This scenario can be confusing to troubleshoot.

RESOLUTION

A Windows NT redirector has been produced that allows a new configurable behavior, accepting the first transport to complete a call, and immediately canceling the calls on the others. A new version of NetBT that supports better handling of multiple calls and cancels is also available.

To take advantage of this improvement, a registry parameter must be added as follows:

WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk. 

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters

   Value Name: IgnoreBindingOrder
   Value type: REG_DWORD
   Default: 0

   Setting this value to "1" causes the redirector to accept the first
   transport to complete a call, rather than waiting for success or failure
   on the "primary" transport.

STATUS

Microsoft has confirmed this to be a problem in Windows NT version 4.0. This problem was corrected in the latest Microsoft Windows NT 4.0 U.S. Service Pack. For information on obtaining the service pack, query on the following word in the Microsoft Knowledge Base (without the spaces): 

   S E R V P A C K

MORE INFORMATION

This problem and hotfix do not apply to Windows Sockets-based connections. When a Windows Sockets application places a call from a multi-homed host the best local source address is chosen automatically (using the route table), unless the application specifies otherwise by choosing a local IP address to use in the bind() call. 

Keywords          : kbbug4.00 kbfix4.00 kbfix4.00.sp2 NTSrvWkst nttcp kbnetwork kbbuglist kbfixlist
Version           : 4.0
Platform          : winnt
Issue type        : kbbug
Solution Type     : kbservicepack

================================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: August 14, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.