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.

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

Reply via email to