Registrations are now open. Join us today!
There is still a lot of work to do on the wiki yet! More information about editing can be found here.
Already have an account?

Microsoft KB Archive/131736

From BetaArchive Wiki

Article ID: 131736

Article Last Modified on 11/1/2006



APPLIES TO

  • Microsoft Windows NT Workstation 3.5
  • Microsoft Windows NT Workstation 3.51
  • Microsoft Windows NT Workstation 4.0 Developer Edition
  • Microsoft Windows NT Server 3.5
  • Microsoft Windows NT Server 3.51
  • Microsoft Windows NT Server 4.0 Standard Edition



This article was previously published under Q131736

SUMMARY

If you have a multihomed computer, the Windows NT implementation of TCP/IP will help to distribute the number of connections, or sessions among the adapters according to a randomizing algorithm. However, truly balancing the network throughput among multiple network interface cards (NICs) has no current practical implementation on PC networks.

MORE INFORMATION

Perfect load balancing, meaning even network bandwidth on all NICs, is not possible. It would necessitate connection oriented network traffic to be dynamically switched between NICs.

However, Windows NT is able to distribute connections from clients across multiple NICs. This helps to spread out the network traffic.

Examples Without WINS

Case 1:

You have multiple NICs in a computer which are connected to separate segments. These segments are not connected by any routers or bridges. No load balancing or distribution of connections takes place at all.

Case 2:

You have a multihomed server, and all of the clients have equal access through the network to any of the NICs in the server. Configure each NIC in the server for its own subnet and distribute the clients among those same subnets. Again, the load balancing achieved here is by virtue of physically distributing the clients across multiple subnets since IP traffic from the clients will be sent to the NIC which has the same subnet address as the client.

Case 3:

In this case, all clients have equal network access to any of the NICs on the multihomed computer. Let all of the client's and server's NICs be on the same subnet. A client sends out a broadcast name query. This request will be received by all of the server's adapters. All of the server's adapters will respond to the client's query and each server adapter's response will contain only one returned address: its own. The client connects with the first adapter to respond and the client drops response packets from the server's other adapters.

Case 4:

Assume that you have the same setup as case 3. Clients have equal access to all of the server's NICs, and all clients and server NICs are on the same subnet. Here you can help to distribute the client connections between the server NICs by enabling the RandomAdapter in the Registry. In this way, each NIC will still respond to the name query, but each NIC will choose the IP address randomly from all the NICs on the server. This helps to distribute network sessions among the NICs, but does not necessarily balance the load since network traffic may vary greatly between the sessions.

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.

To do this, you will need to add the parameter RandomAdapter under the following subkey:

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters
                



For additional information, please see the following article in the Microsoft Knowledge Base:

120642 TCP/IP and NBT Configuration Parameters for Windows 2000 or Windows NT



Examples with WINS Enabled

Case 1:

All your clients are running Windows NT, Windows for Workgroups with TCP/IP- 32, or Windows 95.

Assume all clients and all NICs for the multihomed computer are on the same subnet, and let all clients have equal access to any NIC on the server. Assume a WINS server exists on the network and the WINS server is not the multihomed server.

In this case the multihomed computer has registered each of its NIC addresses under the same NetBIOS name with the WINS server. That is, it registered itself as a multihomed computer. When a WINS client sends a name query, it goes to the WINS server, and the WINS server returns a list of all IP addresses registered for the multihomed computer. The WINS client chooses from this list of multiple IP addresses according to the following algorithm:

  1. Match the NIC's subnet address with the client's address.
  2. Or, if step 1 fails, match the network address of the NIC with the client's network address.
  3. If both steps 1 and 2 fail, choose randomly from the server's list of all adapter IP addresses. If both steps 1 and 2 result in multiple matches, choose randomly from the matching list.

NOTE: The RandomAdapter parameter has no effect for these WINS clients.

Case 2:

You have clients on the WINS network which are not WINS aware or which do not have the WINS feature enabled. These clients respond to the RandomAdapter parameter set on the multihomed computer in the same way as Case 4 above. In fact, the RandomAdapter flag only applies for broadcast name queries from non-WINS aware or non-WINS enabled clients (for example, a Windows NT computer with WINS turned off).

Additional Notes

Employing multiple NICs may not actually improve network throughput in some cases. Suppose, for example, that multiple NICs are configured to contend for traffic on the same segment or wire. The improved efficiency of today's NICs are such that slow downs may occur because of lack of bandwidth on the wire before a single NIC loses efficiency in handling the load. Today's standard ethernet wire transfer data at 10 MB/sec, but bandwidth for current NIC technology far exceeds this rate. A more effective way to improve throughput may be to connect a single ethernet NIC to a 100 MB/sec ethernet link.


Additional query words: prodnt TCP

Keywords: kbnetwork KB131736