yahoo-eng-team team mailing list archive

[Slawek Kaplonski <1884723@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

It was originally reported by Matt Flusche in Red Hat's bugzilla. Below
is description of the issue:

I was verifying these OVS configuration options and the impact on tenant
networking.  My thought going into testing was vxlan would not be
impacted but vlan tenant would break; however, for vxlan tenant networks
it looks like these options will break multicast also.

In a lab test (osp13), multicast is broken between VM instances on
different compute nodes after applying:

>  # ovs-vsctl set Bridge br-int mcast_snooping_enable=true
>  # ovs-vsctl set Bridge br-int other_config:mcast-snooping-disable-flood-unregistered=true

The following can be used to temporarily allow multicast over vxlan:

ovs-vsctl set Port patch-tun other_config:mcast-snooping-flood-
reports=true

This will flood reports to br-tun and the other vxlan endpoints will
learn the remote port.  This allows multicast snooping to work for a
period of time; however, since there is no IGMP querier to continue to
solicit IGMP reports once the Age timer expires (300 secs) the traffic
will be blocked.

It seems that this solution as suggested will work if only provider
networking is used.  Is that correct?

An options that might work would be:

ovs-vsctl set Bridge br-int mcast_snooping_enable=true
ovs-vsctl set Bridge br-int other_config:mcast-snooping-disable-flood-unregistered=false  #<--- change to false; default

Then, for each patch on br-int:

ovs-vsctl set Port <patch> other_config:mcast-snooping-flood-reports=true
ovs-vsctl set Port <patch> other_config:mcast-snooping-flood=true

This might provide best effort snooping.  multicast isolation where IGMP
queriers are available and flood everywhere else?

** Affects: neutron
     Importance: Medium
     Assignee: Slawek Kaplonski (slaweq)
         Status: Confirmed


** Tags: ovs

** Changed in: neutron
     Assignee: (unassigned) => Slawek Kaplonski (slaweq)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1884723

Title:
  [OVS] multicast between VM instances on different compute nodes is
  broken with IGMP snooping enabled

Status in neutron:
  Confirmed

Bug description:
  It was originally reported by Matt Flusche in Red Hat's bugzilla.
  Below is description of the issue:

  I was verifying these OVS configuration options and the impact on
  tenant networking.  My thought going into testing was vxlan would not
  be impacted but vlan tenant would break; however, for vxlan tenant
  networks it looks like these options will break multicast also.

  In a lab test (osp13), multicast is broken between VM instances on
  different compute nodes after applying:

  >  # ovs-vsctl set Bridge br-int mcast_snooping_enable=true
  >  # ovs-vsctl set Bridge br-int other_config:mcast-snooping-disable-flood-unregistered=true

  The following can be used to temporarily allow multicast over vxlan:

  ovs-vsctl set Port patch-tun other_config:mcast-snooping-flood-
  reports=true

  This will flood reports to br-tun and the other vxlan endpoints will
  learn the remote port.  This allows multicast snooping to work for a
  period of time; however, since there is no IGMP querier to continue to
  solicit IGMP reports once the Age timer expires (300 secs) the traffic
  will be blocked.

  It seems that this solution as suggested will work if only provider
  networking is used.  Is that correct?

  An options that might work would be:

  ovs-vsctl set Bridge br-int mcast_snooping_enable=true
  ovs-vsctl set Bridge br-int other_config:mcast-snooping-disable-flood-unregistered=false  #<--- change to false; default

  Then, for each patch on br-int:

  ovs-vsctl set Port <patch> other_config:mcast-snooping-flood-reports=true
  ovs-vsctl set Port <patch> other_config:mcast-snooping-flood=true

  This might provide best effort snooping.  multicast isolation where
  IGMP queriers are available and flood everywhere else?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1884723/+subscriptions