Article ID: 257577 - View products that this article applies to.
This article was previously published under Q257577
This article has been archived. It is offered "as is" and will no longer be updated.
If your program uses the gethostbyname function, the returned list of IP addresses may not include the virtual IP addresses created by the Cluster service, or it may list IP addresses that are not currently owned by this node.
When the Cluster service adds or removes a virtual IP address, the TCP/IP protocol does not update the cache from which it returns the IP addresses.
To resolve this problem, obtain the latest service pack for Windows 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
260910The English version of this fix should have the following file attributes or later:
(http://support.microsoft.com/kb/260910/EN-US/ )How to Obtain the Latest Windows 2000 Service Pack
File name: Q257577_w2k_sp2_x86_en.exeThis package includes updated versions of:
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Windows 2000 Service Pack 2.
In Windows NT 4.0, gethostbyname(local node name) returned a list containing all IP addresses instantiated on the server, including cluster virtual IP addresses. In Windows 2000, the same operation usually returns only the IP addresses that are permanently assigned to the server; however, it can sometimes return the entire list just like Windows NT 4.
The behavior change is a side effect of the implementation of the DNS resolver service. The resolver caches the list of local IP addresses at startup. When it is asked to resolve the local node name, it returns the list from its cache instead of consulting a DNS server. The problem is that the resolver does not listen for PNP address change notifications from the TCP stack, but it does receive these notifications from the DHCP client. When the resolver receives a change notification from DHCP, it updates its cached list of local IP addresses by querying the TCP stack. The result is that when clustering instantiates a new address, the resolver does not learn about it unless/until a subsequent DHCP address change occurs. The same is true when cluster addresses are removed. Since DHCP address changes are rare, gethostbyname usually excludes cluster IP addresses when resolving the local node name.
In Windows 2000, MSMQ came to depend on the new behavior in its active/active scenario in a cluster and is therefore broken with the hotfix behavior. MSMQ uses RPC for client/server communication. At startup in the server process, RPC uses gethostbyname to determine the list of IP addresses to listen on. In its active/active configuration, one MSMQ server process is associated with the local node name, while another is associated with a cluster virtual server. If gethostbyname returns the virtual server IP address to the process associated with the local node name, then both processes will listen on that address. The result is that clients attempting to connect to the virtual server process can be mistakenly connected to the local node's process. Thus, MSMQ depends on the fact that cluster virtual IP addresses usually are not returned by gethostbyname when resolving the local node name.