[ovs-dev] Support for MCAST_Snooping

[Aman Kumar]

Yes, Please do the patch against branch master and inform me, i will test
it with branch master.
Currently i am using the branch master only.

Thanks
Aman Kumar
HP India

On Wed, Dec 10, 2014 at 12:57 AM, Flavio Leitner <fbl at redhat.com> wrote:

> On Wed, Dec 10, 2014 at 12:09:07AM +0530, Aman Kumar wrote:
> > > 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).
>
> OK, IIRC the RFC allows to administratively configure the port to forward
> Reports and that should be straightforward with the current code.
>
> If I do the patch against branch master, would you be able to test it?
>
> fbl
>
>
> >
> > 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
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >
> > >
>