Multihomed Issues with Windows NT

Adding additional network interface cards in a computer running Windows NT Server requires that several issues be considered. To better manage these issues and to increase the reliability of mission critical systems, a reduction in services that are running on the system should be considered. Many of the services running on a mission-critical computer such as the primary domain controller can be off-loaded to other computer to increase reliability. This article applies to Windows NT version 4.0 with Service Pack 3.

NetBIOS does not have a problem with multihomed environments. An exception to this is with the NetBEUI protocol. If this protocol is used, and if the two interfaces are directly connected to the same physical segment, or indirectly connected through an intermediate system such as a bridge, NetBEUI must be unbound from one of the network interfaces. All of the other protocols that support NetBIOS do not have this problem. For TCP/IP, NetBIOS binds to the primary IP address bound to each network interface card (NIC).

For information on multihomed WINS servers and Multihomed WINS clients, please see the following articles in the Microsoft Knowledge Base: DHCP does not have a problem with multihomed servers. It binds to all NICs, and the service issues the correct scopes. Like NetBIOS, DHCP binds to the primary IP address bound to each NIC.

For additional information, please see the following article in the Microsoft Knowledge Base: DNS, if bound to all NICs, does not have a problem in a multihomed environment. The DNS service will send a Listen for port 53 and the DNS server will respond to requests on all NICs. Netlogon does not have any functional problem with multihomed computers. Browsing is very much affected by multihomed computers. Because the browser service does not merge networks, the primary domain controller (PDC) cannot be multihomed. Each browser service bound to each interface operates independently, and the PDC maintains a "separate" cumulative list on each interface that are not merged. A master browser that exchanges lists with the PDC on one interface will not obtain servers discovered by a master browser that is exchanging lists on the other interface.

Windows NT 4.0 introduced the UnboundBindings setting, and this can be used to prevent the PDC from directly gathering a browse list on more than one interface. Unfortunately, this setting does not force the master browsers in the domain to use only the bound interface card. If WINS is used to provide the IP address for the master browser to find the PDC, there is no way of guaranteeing that the correct interface will be chosen. This limitation cannot be overcome with Windows NT 4.0 and the PDC must not be a multihomed computer to guarantee that it can merge a single domain-wide list. Also, master browsers cannot be multihomed. Because only one IP address is maintained for session establishment to a computer name, and the PDC communicates with a master browser based on its computer name alone, the PDC can only collect the local list of servers discovered by the multihomed master browser from one of its interfaces. CSNW and GSNW: Both Client Services for NetWare (CSNW) and Gateway Services for NetWare (GSNW) only bind to a single network interface, and, by default, this is the first bound NIC in the system. A symptom of this is that users can only connect to servers on one interface and not on the other. The Get Nearest Server query is only sent from the bound NIC, and if the two interfaces are not connected through a router, the servers available will only be on that bound NIC side.

Multihomed Performance: Prior to Windows NT 4.0 Service Pack 3, the redirector waits for the first bound transport to complete before accepting a NetBIOS over TCP/IP connection on additional endpoints. Because of this, multihomed computers may have an extended delay in establishing a session if the multihomed segments are disjointed. Or, if the networks are connected by a router, the path chosen may not be optimal. Also, the network traffic between the client and server may be taking two different paths because of internal routing on the multihomed computer. In either case, the connection ultimately succeeds.

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