Windows Server 2008 Failover Clusters: Networking (Part 4)

Windows Server 2008 Failover Clusters: Networking (Part 4)

  • Comments 12
  • Likes

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.

clip_image002

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’. 

clip_image004

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).

clip_image005

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).

clip_image007

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}

clip_image009

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.

clip_image011

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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • 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..

  • 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

      disabled:  Public-1

      disabled:  Public-2

      disabled:  Public-3

      disabled:  Public-4

      enabled:   iSCSI-1

      enabled:   iSCSI-2

      enabled:   iSCSI-3

      enabled:   iSCSI-4

    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)

      Subnet Mask . . . . . . . . . . . : 255.255.255.0

      IPv4 Address. . . . . . . . . . . : 192.168.1.64(Preferred)

      Subnet Mask . . . . . . . . . . . : 255.255.255.0

      Default Gateway . . . . . . . . . : 192.168.1.1

      DNS Servers . . . . . . . . . . . : 192.168.1.51

      NetBIOS over Tcpip. . . . . . . . : Enabled

    Ethernet adapter CLUSTER HB - 10.1.100.61:

      Connection-specific DNS Suffix  . :

      Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection #3

      Physical Address. . . . . . . . . : 00-0C-29-D7-60-FB

      DHCP Enabled. . . . . . . . . . . : No

      Autoconfiguration Enabled . . . . : Yes

      IPv4 Address. . . . . . . . . . . : 10.1.100.61(Preferred)

      Subnet Mask . . . . . . . . . . . : 255.255.255.0

      Default Gateway . . . . . . . . . :

      NetBIOS over Tcpip. . . . . . . . : Enabled

    Ethernet adapter ISCSI -10.2.100.61:

      Connection-specific DNS Suffix  . :

      Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection #2

      Physical Address. . . . . . . . . : 00-0C-29-D7-60-F1

      DHCP Enabled. . . . . . . . . . . : No

      Autoconfiguration Enabled . . . . : Yes

      IPv4 Address. . . . . . . . . . . : 10.2.100.61(Preferred)

      Subnet Mask . . . . . . . . . . . : 255.255.255.0

      Default Gateway . . . . . . . . . :

      NetBIOS over Tcpip. . . . . . . . : Enabled

    Ethernet adapter Local Area Connection* 9:

      Connection-specific DNS Suffix  . :

      Description . . . . . . . . . . . : Microsoft Failover Cluster Virtual Adapter

      Physical Address. . . . . . . . . : 02-0C-29-D7-60-E7

      DHCP Enabled. . . . . . . . . . . : No

      Autoconfiguration Enabled . . . . : Yes

      IPv4 Address. . . . . . . . . . . : 169.254.1.57(Preferred)

      Subnet Mask . . . . . . . . . . . : 255.255.0.0

      Default Gateway . . . . . . . . . :

      NetBIOS over Tcpip. . . . . . . . : Enabled

  • 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

  • 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?

    Tks

  • 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.

  • 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?)