Microsoft Enterprise Platforms Support: Windows Server Core Team
EPS Team Blogs
Product Team Blogs
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 –
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
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?
I have an issue that sounds very related, but I have already verified the order of the bindings and it looks ok. The Microsoft Failover Cluster Virtual Adapter is listed in the order - after the public, cluster heardbeat and live migration nics. DNS wise all looks great, netbios also looks ok, BUT not ping -a with the local hostname!
"ping -a myhostname" returns the APIPA address of the Microsoft Failover Cluster Virtual Adapter and not the IP address from the public lan. Is this correct or a bug?
Take a look yourself:
"Internet Protocol Version 4 (TCP/IPv4)":
enabled: Public Virtual Switch
enabled: Cluster Communications
enabled: Live Migration
disabled: Public Team #1
enabled: Local Area Connection
enabled: Local Area Connection* 9
and "ping -a [hostname]" (not IP) return the APIPA address!???
First thank you for your blog ...
And maybe you can help me ?
- The Microsoft Failover Cluster Virtual Adapter is bind on the wrong physical interface.
(my PUBLIC interface) so how can i change this ?
- The Microsoft Failover Cluster Virtual Adapter used an APIPA IP i did not want that
i'd like to use my own vlan so how can i change this ?
mayb be there is a way in the "Failover Cluster Management" console ...
But i did not find ...
I'd like to see soon a new chapitre on this subject ...
Windows IP Configuration
Host Name . . . . . . . . . . . . : sql-node01
Primary Dns Suffix . . . . . . . : gb.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : gb.local
Ethernet adapter PUBLIC - 192.168.1.61:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
Physical Address. . . . . . . . . : 00-0C-29-D7-60-E7
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.1.61(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IPv4 Address. . . . . . . . . . . : 192.168.1.63(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.64(Preferred)
Default Gateway . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.51
NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter CLUSTER HB - 10.1.100.61:
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection #3
Physical Address. . . . . . . . . : 00-0C-29-D7-60-FB
IPv4 Address. . . . . . . . . . . : 10.1.100.61(Preferred)
Default Gateway . . . . . . . . . :
Ethernet adapter ISCSI -10.2.100.61:
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection #2
Physical Address. . . . . . . . . : 00-0C-29-D7-60-F1
IPv4 Address. . . . . . . . . . . : 10.2.100.61(Preferred)
Ethernet adapter Local Area Connection* 9:
Description . . . . . . . . . . . : Microsoft Failover Cluster Virtual Adapter
Physical Address. . . . . . . . . : 02-0C-29-D7-60-E7
IPv4 Address. . . . . . . . . . . : 169.254.1.57(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
For the hidden adapter scenario the MS KB 981953 provides the proper steps in the section titled "How to change the Hosts file".
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.
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.
Article ID: 981953 - Last Review: May 17, 2010 - Revision: 2.0
An 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
U save my day... Tks.
Just one question:
In binding the network order is 1st HB or Public interfase?
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.
Thank you very much, Fantastic information.
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?)