Manage Learn to apply best practices and optimize your operations.

Solve multicast snooping problems in a bridged environment

Disabling multicast snooping is sometimes the only way to make sure cluster traffic is handled correctly in a KVM environment.

When setting up a virtual environment on a Linux-based hypervisor, you'll normally work with software bridges....

These software bridges allow virtual machines to share access to the physical network adapter with the host computer. In some cases, software bridges don't react like physical bridges or other devices. This is the case when dealing with multicast. In this article, you'll read how to configure a software bridged environment to handle multicast traffic correctly.

On many networks, multicast traffic is not really needed. The design purpose behind multicast traffic is that it can be used as a kind of IP address for a group. In some specific cases however, applications need the capability to send multicast traffic. An example of such a situation is high availability clustering, where nodes in the cluster use multicast traffic to communicate.  

In a physical network, if all the cluster nodes are connected to the same physical switch, there are no issues with multicast. On many networks, different switches are connected to each other to create one big broadcast domain. If that is the case, you need to take specific action to make sure multicast packets originating from one switch are forwarded to all other switches as well. In a virtualized environment, physical KVM hosts are typically connected to a physical switch, while the virtual machines on that host connect to the virtual bridge. So, in this scenario, multiple bridges or switches are interconnected.

Configuring multicast snooping

In order to allow a smooth transition of multicast traffic between multiple switches and bridges, you will need multicast snooping (also referred to as IGMP snooping). Multicast snooping causes the switch to forward multicast packets only to those switch ports where a multicast address has been detected. In general, this is good because it makes sure all other nodes are not receiving the multicast packet. However, it may cause problems on networks where switches are interconnected. Cluster nodes use multicast to communicate by default, meaning cluster nodes will not be able to see one another. If this happens, you may consider switching off multicast snooping completely on the switches (which will degrade performance). In a KVM virtualized environment, disabling multicast snooping is the only way to make sure that multicast traffic is handled correctly.

If your switch is a virtual bridge device -- which is common in KVM and Xen virtualized environments -- you can modify the multicast snooping behavior by changing a parameter in the sysfs file system. In /sys/class/net, every configured bridge has a sub directory, /sys/class/net/br0, for example. In this directory you'll find the bridge multicast snooping file, which by default has a value of "1" to enable multicast snooping. If you're experiencing problems with multicast, change the value of this file to "0" by echoing the value into the file. If that works, you can also try the value "2," which enables multicast snooping but in a smart mode that is designed to work between different interconnected switches.

To automate this configuration setting, you should include it somewhere in the boot procedure. You can do this by modifying the /etc/init.d/boot.local file on the KVM host Linux distribution to include the following script lines:

# set multicast_snooping
cd /sys/class/net
for i in br*
do
     echo 0 > br$i/bridge/multicast_snooping
done

In this article, you've learned how to configure virtual bridges in a KVM environment to deal with multicast problems. You've read how switching the multicast snooping parameter helps you ensure that multicast traffic is handled smoothly when multiple physical switches and virtual bridges are interconnected.

Next Steps

Does an open source hypervisor stand a chance?

Citrix aims to win over cloud customers with open source XenServer

Building a KVM high availability cluster on a budget

This was last published in September 2014

Dig Deeper on Open source virtualization

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchVMware

SearchWindowsServer

SearchCloudComputing

SearchVirtualDesktop

SearchDataCenter

Close