Windows Server 2008 Failover Clusters: Networking (Part 4)
The Windows Server 2008 Failover Clustering: Networking three-part blog series has been out for a little while now. Hopefully, it has been helpful. Little did I know there would be an opportunity to write another part. This segment will be short as it covers a very specific scenario. One that we rarely see, but we have encountered it enough that I felt it might be worth writing about it.
There are applications written to access resources that are being hosted in Microsoft clusters running on Windows Server 2008 (RTM + R2). The resource could be a File Server, could be a SQL database, or whatever. The point is that the required resource is being hosted in a Failover Cluster. It is hoped that applications that need to function in this manner are written properly to locate the required resource being hosted in a cluster. By that I mean I would expect an application to be written in a manner where it would first query a name server (DNS server) and then use the information obtained to make a proper connection to the required cluster resource. In a Failover Cluster, that connection point is known as a Client Access Point (CAP). A CAP consists of a Network Name (NetBIOS) resource and one or more IP Address resources. The default behavior in a Windows Server 2008 cluster is to dynamically register CAP information in a DNS server provided it is configured to support Dynamic Updates. This occurs when the CAP is brought Online in the cluster. There are applications that are not written in this manner. There are some application that are written in such a way that they will make a local connection on a cluster node by binding to the first network adapter and then use the IP address configured for that adapter. The end result is in a cluster, the first connection listed in the binding order by default is the Microsoft Failover Cluster Virtual Adapter. This adapter uses an IP address that is drawn from the APIPA (Automatic Private IP Addressing) address range which is non-routable and not registered in DNS.
To assist with helping make these types of applications work better, we can use a utility that has been released for public download on the Microsoft MSDN site. The utility is called ‘nvspbind.’ So, the first step is to download and install the utility on each cluster node. The options we will be using are shown in Figure 1.
Figure 1: Options for nvspbind
First we need to identify the adapter that is the Microsoft Failover Cluster Virtual Adapter by using the nvspbind /n command (Figure 2). The adapter is ‘Local area connection* 9’.
Figure 2: Identify the Microsoft Failover Cluster Virtual Adapter
Next, we use the 'nvspbind /o ms_tcpip’ to determine the binding order for IPv4 (Figure 3).
Figure 3: Listing the bindings for IPv4
We can see here, that the adapter is listed at the top of the binding order for IPv4 which is causing the problem for some applications. We need to move the adapter down in the binding order so we will use the following command to accomplish that –
C:\nvspbind /- “local area connection* 9” ms_tcpip (Figure 4).
Figure 4: Moving the adapter down in the binding order for IPv4
Note: The adapter can be moved further down by using /-- if desire.
Once the adapter has been positioned correctly in the binding order, the application can be tested to see if it now works as desired.
To further highlight the effect of this utility, we can inspect the registry. First, we need to locate some information for the Microsoft Failover Cluster Virtual Adapter. Navigating to the following registry key (Figure 5), and locate the adapter –
HKEY_LOCAL_MACHINE\SYSTEM\CurrenControlSet\Class\{4D36E972-11CE-BFC1-08002BE10318}
Figure 5: Microsoft Failover Cluster Virtual Adapter NetCfgInstanceId
The same information shown in Figure 5 is also displayed in Figure 2.
With the information in hand, navigate to the following registry key (Figure 6) to verify the adapter is no longer listed at the top of the binding order.
Figure 6: HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Linkage
That’s about it. Thanks for your time and, as always, we hope the information here has been useful to you.
Chuck Timon
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support
Comments
- Anonymous
January 01, 2003
The comment has been removed - Anonymous
January 01, 2003
The comment has been removed - Anonymous
January 01, 2003
Hi Chuck, This whole series has been very interesting to read so thanks very much for that.One question... Can you give us an example of a cluster resource that is not playing by the rules as above? I am assuming all Microsoft written cluster resources are all OK?Also would you consider doing a blog post on the new Cluster powershell cmdlets for R2? Say how to use them to build a whole cluster?:)Cheers,Packetboy.. - Anonymous
March 15, 2011
For the hidden adapter scenario the MS KB 981953 provides the proper steps in the section titled "How to change the Hosts file".support.microsoft.com/kb/981953 - Anonymous
March 15, 2011
From the Microsoft (MS) KB article link above for the non-working Virtual Adapter(s) please follow the instructions in the MS KB and add the adapters in the proper format to the hosts files on the Cluster nodes.Note: Don't forget to do the last step and use ipconfig /flushdns to reload the new hosts file entries. This will make/enforce the changes without requiring a server reboot. - Anonymous
March 15, 2011
You can not always blame the application for the issue. This article should be amended to clarify the issue not point the blame where it may not be. - Anonymous
March 15, 2011
Article ID: 981953 - Last Review: May 17, 2010 - Revision: 2.0An incorrect IP address is returned when you ping a server by using its NetBIOS name in Windows Server 2008 or in Windows Server 2008 R2 - Anonymous
July 24, 2012
U save my day... Tks.Just one question:In binding the network order is 1st HB or Public interfase?Tks - Anonymous
August 06, 2013
Hello,I've followed this article, but ping on the host himself still answer with Failover Cluster VIrtual Adapter.How can we "fix" this, without changing the host file ?Thanks for helping. - Anonymous
November 11, 2013
Thank you very much, Fantastic information. - Anonymous
December 08, 2013
In addition to this, you might have to also modify the interface metric of the Failover Cluster Virtual Adapter, so that when you ping the local host name, it will ping the real IP address instead of the 169.254 address. See support.microsoft.com/.../894564 for details. (Not sure if this is safe though, can someone at Microsoft confirm?) - Anonymous
May 19, 2014
Hi
I think this will solve our issue however your link to the download no longer works and Google isn't being much help either as they all point to the page that now no longer exists in MS.
Can you post up a new link for us to use please.
Thanks