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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 < > [email protected] > > > > > > > > > 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 <[email protected]> > > > 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 > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > > > > > > _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
