[ovs-dev] Support for MCAST_Snooping

[Aman Kumar]

> mcast-snooping-flood=true,  Once you enable that on a port, all
multicast traffic (but not Reports) will be sent over that port

I have enabled "mcast-snooping-flood=true" on my port patch-tun and in this
case all traffic including Reports are reaching to other side i.e on OVS2,
since report is coming from a port where action is not NORMAL, ovs2 is not
able to snoop that port.
And its true, ovs2 is doing its own work if packet coming from patch-tun is
registered then it is sending to a particular host who has registered for
the same group.

But in this case all packets are reaching from ovs1 to ovs2 even though
there is no receiver on ovs2 and traffic on tunnel is getting unnecessarily.
My point is that, if ovs will be able to learn that port (in my case
patch-tun which is connected to another bridge) then it will send multicast
packet out (on patch-tun) only if there will be a receiver on ovs2 and it
will reduce the underlay traffic (traffic on tunnel).

On Tue, Dec 9, 2014 at 10:38 PM, Flavio Leitner <fbl at redhat.com> wrote:

> On Tue, Dec 09, 2014 at 06:49:36PM +0530, Aman Kumar wrote:
> > Now i got why ovs2 is not able to snoop the vm1's(running on ovs1) igmp
> > request, it's because action for patch-tun is not normal.
> >
> > But for action= NORMAL ovs is not sending the igmp report (or any packet)
> > to patch-tun. Port patch-tun is on bridge br-int and it's connected to
> > bridge br-tun(on same ovs).
> > ovs does not have learning capacity for the port patch-tun, so can you
> > implement and fix this issue for the next release of ovs, so that ovs can
> > also learn the port which is connected to another bridge.
>
> Why would one forward a IGMP Report? It's meant to say to the local
> bridge that there is a host interested in receiving multicast traffic.
> The only reason I see is to enable sending multicast traffic through
> a port that doesn't have a host behind.  For that there is the port's
> option mcast-snooping-flood=true.  Once you enable that on a port, all
> multicast traffic (but not Reports) will be sent over that port and the
> other side is free to decide what to do with them (snooping or not).
>
> ovs-vsctl set Port <port> other_config:mcast-snooping-flood=true
>
> Notice that you need to do that in both ends for tunnel/patch ports
> and in your case in the intermediate tunnel/patch ports too.
>
> If the above is correct, check the packet's TTL.
>
> fbl
>
>
> > Please refer diagram mailed by me on  10:28pm 8th dec (GMT + 5:30)
> >
> > On Tue, Dec 9, 2014 at 6:34 PM, Aman Kumar <amank3107 at gmail.com> wrote:
> >
> > > Hi,
> > >
> > >     It is a openstack setup that we are using. To be more clear with
> the
> > > configuration:
> > >
> > >      -> we have set  *mcast_snooping_enable=true* on *br-int* of OVS on
> > > both the compute nodes.
> > >
> > >      -> *mcast-snooping-flood=true *for *Patch-tun* port of br-int on
> > > both compute nodes ( so that the multicast traffic reaches the compute
> node
> > > 2 via br-tun through patch-tun).
> > >
> > > we can see that the igmp membership report is recieved on *br-int* (via
> > > patch-tun) of compute node 2 ,which may be sent via vm1 or vm2( Acting
> as
> > > Recievers) .Flows on* br-int *of the compute nodes have "*normal*"
> > > action. An *mdb/show* on the first compute node shows that the packets
> > > have been snooped. The same is not true for the second compute node. Is
> > > there something amiss here?
> > >
> > > On Tue, Dec 9, 2014 at 9:51 AM, Neethi Shashidhar <neethi209 at gmail.com
> >
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >>     It is a openstack setup that we are using. To be more clear with
> the
> > >> configuration:
> > >>
> > >>      -> we have set  *mcast_snooping_enable=true* on *br-int* of OVS
> on
> > >> both the compute nodes.
> > >>
> > >>      -> *mcast-snooping-flood=true *for *Patch-tun* port of br-int on
> > >> both compute nodes ( so that the multicast traffic reaches the
> compute node
> > >> 2 via br-tun).
> > >>
> > >> we can see that the igmp membership report is recieved on *br-int*
> (via
> > >> br-tun) of compute node 2 ,which may be sent via vm1 or vm2( Acting as
> > >> Recievers) .Flows on* br-int *of the compute nodes have "*normal*"
> > >> action. An *mdb/show* on the first compute node shows that the packets
> > >> have been snooped. The same is not true for the second compute node.
> Is
> > >> there something amiss here?
> > >>
> > >> Regards,
> > >> Neethi
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Tue, Dec 9, 2014 at 1:04 AM, Flavio Leitner <fbl at redhat.com>
> wrote:
> > >>
> > >>> On Mon, Dec 08, 2014 at 10:28:14PM +0530, Aman Kumar wrote:
> > >>> > Hi all,
> > >>> >
> > >>> > Thanks again, because of your help it is working fine but i have a
> > >>> problem
> > >>> > with 2 compute nodes(each one is having different OVS),
> > >>> > below is the complete scenario.
> > >>> > [image: Inline image 1]
> > >>> >
> > >>> > Here, when receiver VM1 sends IGMP v2 reports, it reaches to OVS2
> also
> > >>> but
> > >>> > only OVS1 is able to Snoops that but OVS2 is not able to snoop.
> > >>> > So, Now my question is that does ovs snoops only to those ports
> which
> > >>> is
> > >>> > connected to host?
> > >>> > Can't it snoop the other port which is not connected to host but
> IGMP
> > >>> > report is coming from there?
> > >>> > here br-tun and br-int is bridges on ovs, i have enabled the
> snooping
> > >>> on
> > >>> > br-int
> > >>>
> > >>> I am confused with your problem description.  If you configured the
> > >>> port as multicast flood port or if it is a multicast router port,
> then
> > >>> the bridge will not learn any Report coming there because they are
> > >>> automatically used to send multicast packets anyway.  Flood ports are
> > >>> configured by the admin.  The mcast router port is automatically set
> > >>> when a Query is received (you can check in the mdb).
> > >>>
> > >>> Other than that, the bridge should snoop any packet passing through
> it
> > >>> using the action NORMAL regardless if it's connected to a host or
> not.
> > >>>
> > >>> fbl
> > >>>
> > >>>
> > >>>
> > >>
> > >
>