KVM virbr# no longer forwards multicast traffic by default (U12.04)

Bug #1218959 reported by Michael Cook
24
This bug affects 2 people
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Fix Released
High
Unassigned
Precise
Fix Released
High
Unassigned
linux (Ubuntu)
Fix Released
High
Unassigned
Precise
Won't Fix
High
Unassigned

Bug Description

A recent kernel update (Apr 2013) has made it's way to U12.04.2 LTS (approx June-Aug 2013) and has stopped the (default) behaviour of automatically forwarding multicast traffic over virbr#. Some updates the bridge subsystem now, by default, disable multicast traffic without IGMP Querier being enabled on that bridge.

The corresponding Fedora/RHEL bug tracks the progress/updates of this specific change in relation to Fedora.
https://bugzilla.redhat.com/show_bug.cgi?id=880035

(I have yet to find a similar bug report in Ubuntu so I have created this bug to help the Ubuntu community identify multicast issues that may arise since April 2013 in U12.04 LTS and presumably other Ubuntu releases as backports are made and break regression testing.)

Using the latest patches in U12.04.2 LTS this following addition, with some modifications, can be made to the udev rules will enable multicast on virbr# bridge:
https://bugzilla.redhat.com/show_bug.cgi?id=880035#c38

While this is an improvement/correction to KVM bridge networking it has broken existing functionality in U12.04.2 LTS and broke regressed functionality that once worked.

IMPACT: multicast is broken over libvirt bridges
FIX: set a (new, introduced by a new kernel) toggle on the bridges
TEST CASE: cat /sys/devices/virtual/net/virbr0/bridge/multicast_querier - if 0, then forwarding multicast will be broken.
REGRESSION POTENTIAL: should be none. older kernels do not have the toggle, and failure to set it will be ignored

Changed in bridge-utils (Ubuntu):
status: New → Confirmed
importance: Undecided → High
affects: bridge-utils (Ubuntu) → libvirt (Ubuntu)
Changed in libvirt (Ubuntu Precise):
status: New → Confirmed
importance: Undecided → High
Changed in libvirt (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

This patch should solve this bug. However there is a package in precise-proposed right now, so this will need to be queued up.

Revision history for this message
Max Köhler (yatc18ks0g8zofezrpk3xa7828d3ooa6g-me) wrote :

We are currently facing the same problem. IGMP queries are reaching the bridge but won't hit the TAP device. Can someone tell me, because I wasn't able to get this information on my own, in which version it's fixed?
Also if the commited patch is the only fix does someone know what else could result in this issue because enabling the querier does not work for us?

Thanks!

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

I had thought that we'd need a udev rule to work around this, but looking over the fedora bug in more detail it looks like cherrypicking the two patches mentioned in comment 31 ( https://bugzilla.redhat.com/show_bug.cgi?id=880035#c31 ) should do it.

Can those who are suffering from this bug please tell us precisely which kernel they are using? If I understand right, this should be fixed in 3.11, so I would expect anyone using the saucy backport kernel to not be affected.

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1218959

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Changed in linux (Ubuntu Precise):
status: New → Incomplete
tags: added: precise
tags: added: patch
Revision history for this message
Stefan Bader (smb) wrote :

Serge, looks like we need to be careful with those two. At least one of them:
  "bridge: only expire the mdb entry when query is received"
was reverted with 3.12. The commit message looks a bit like they might have packed several reverts into one. And it references
"bridge: disable snooping if there is no querier" as the one making the reverted stuff obsolete.

description: updated
Changed in linux (Ubuntu):
status: Incomplete → Fix Released
Changed in linux (Ubuntu Precise):
status: Incomplete → Won't Fix
Changed in linux (Ubuntu):
importance: Undecided → High
Changed in linux (Ubuntu Precise):
importance: Undecided → High
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Michael, or anyone else affected,

Accepted libvirt into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/libvirt/0.9.8-2ubuntu17.19 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in libvirt (Ubuntu Precise):
status: Confirmed → Fix Committed
tags: added: verification-needed
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Can someone please test this package so it gets released?

If nobody tests it, it will get superseded by a security update.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1218959] Re: KVM virbr# no longer forwards multicast traffic by default (U12.04)

There has also been some concern about the propriety of the
proposed fix (when a newer kernel with the upstream fixes should
appear), in addition to lack of verifiaction - so please go ahead
and supersede this if you haven't already.

Revision history for this message
Michael Cook (michaelcook-mjc) wrote :

Thanks for the patch and test instructions.

Should this be tested using U12.04.2 LTS or U12.04.4 LTS as a baseline and should I apply updates to the installation first?

A few questions:
1) I don't understand how of the "security update" superceeding this patch affects this problem unless it prevents enabling MC on bridge?
2) There is reference to an independent kernel update to libvirt has addressed this problem and if so, in which kernel. The comment #3 mentioned a redhat bug but the comments of that bug say it's not going to be propagated and looks project specific. Maybe I misread it?
3) I originally applied a udev rule myself, but specific to the single bridged interface I'm using to send multicast over. Your proposed udev patch applies this to all virbr* interfaces. Is this ok/sensible?

Personally, I think for U12.04.2LTS back ports, MC traffic should have simply been left as-is. Future releases should have adopted proper handling of MC traffic and required Querier to be enabled.

Appreciate any insight, thanks.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libvirt - 0.9.8-2ubuntu17.19

---------------
libvirt (0.9.8-2ubuntu17.19) precise-proposed; urgency=medium

  * Add a udev hook and script to enable multicast_querier when a
    virbr* is brought up (LP: #1218959)
 -- Serge Hallyn <email address hidden> Wed, 26 Mar 2014 11:36:55 -0500

Changed in libvirt (Ubuntu Precise):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.