The Case of Multicast Messages not being Received on a Windows Server 2008 R2 Microsoft Failover Cluster

This article is semi-related to Writing a High-Performance C# Application. The application I did that research for has now been extended to use UDP to send data to a large number of clients.

The Problem

UDP messages were received by clients running on other machines. Clients on the same machine (a Windows Server 2008 R2 box running Microsoft Failover Cluster), however, did not receive any message.

For me as a developer, the following analysis was a fun excursion into sysadmin territory, something I only get to do occasionally.

The Cause

In order to subscribe to multicast messages, a client joins a multicast group, identified by a class D network address. Using the command

netsh interface ipv4 show joins

you can see which interfaces are joined to which multicast groups. In other words, you can see on which interface the client listens for incoming multicast messages.

In Windows Server 2008 R2 Microsoft introduced a special adapter called Microsoft Failover Cluster Virtual Adapter (see [1] and [2]). This adapter is hidden in the network adapter UI, but it shows up in the output of the

ipconfig  /all

command.

On the machine in question, the client had joined the multicast group using this virtual adapter instead of the physical adapter that was actually receiving the multicast messages.

When joining a multicast group, an application can specify the interface to use in the ip_mreq structure. In fact, Microsoft recommends it.

The network interface with the lowest value for the routing metric for a destination IP address of 224.0.0.0 is the default interface for IPv4 multicast.

However, if the application does know not anything about the interfaces available on the machine, it can instruct the operating system to use the default multicast interface. This default multicast interface is determined by the IP routing table. You can view the routing table by running the command

route print

As it turns out, the virtual adapter was added to the IP routing table with a metric lower than that of the physical adapter; meaning the virtual adapter would be chosen over the physical one.

The Solution

I adjusted the metric for the virtual adapter using the command below. N is the interface ID of the physical adapter based on the output of “show joins” command above.

netsh interface ipv4 set route 224.0.0.0/4 interface=N siteprefixlength=0 metric=1 publish=yes store=persistent

Afterwards clients started receiving multicast messages. No reboot required.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s