On Mon, Oct 03, 2016 at 09:17:00PM +0000, my_ovs_disc...@yahoo.com wrote: > Thanks Cascardo for the response. > The problem is IGMP querier in Linux kernel sends queries with source IP > 0.0.0.0 and this is being ignored by OVS.Since the current implementation of > mcast-snooping in OVS isn't really tracking the source IP of queriers, can we > relax this source IP 0.0.0.0check for queries? > Thanks >
Do you mean the Linux bridge querier? What is your topology? Do you want OVS to forward the queries from Linux bridge or something like that? Cascardo. > > > > Sent from Yahoo Mail. Get the app > > From: Thadeu Lima de Souza Cascardo <casca...@redhat.com> > To: my_ovs_disc...@yahoo.com > Cc: Discuss <discuss@openvswitch.org> > Sent: Monday, October 3, 2016 7:20 AM > Subject: Re: [ovs-discuss] openvswitch-2.5.0 IGMP-SNOOPING question > > On Fri, Sep 30, 2016 at 01:25:08AM +0000, my_ovs_disc...@yahoo.com wrote: > > Hi, openvswitch-2.5.0 seems to ignore IGMP queries with source IP 0.0.0.0 > > But, RFC seems to say the following: Highlighted in red. > > That switches shouldn't drop queries with source IP 0.0.0.0. > > The highlighted section mentions IGMP *MEMBERSHIP REPORTS*, not queries. That > section refers to switches that implement proxy reporting, which OVS doesn't. > OVS, however, does not add to the list of multicast routers the ports where > IGMP > queries with source address 0.0.0.0 arrives (unless queries with other source > addresses arrive, that is). That is in complicance with this same quote, see > item B below. > > Did you mean that queries with source address 0.0.0.0 are not forwarded? In > that > case, OVS will look at the destination address and send only to those ports > that > belong to that multicast group. If it's a membership report, OVS will send > only > to ports belonging to multicast routers. > > Does this behavior you see cause any real problem? Like some multicast traffic > not reaching some destinations? > > Regards. > Cascardo. > > > > > RFC 4541 IGMP and MLD Snooping Switches Considerations May 2006 > > > > > > This is not a problem in an IGMPv3-only network because there is > > no suppression of IGMP Membership reports. > > > > The administrative control allows IGMP Membership Report messages > > to be processed by network monitoring equipment such as packet > > analyzers or port replicators. > > > > The switch supporting IGMP snooping must maintain a list of > > multicast routers and the ports on which they are attached. This > > list can be constructed in any combination of the following ways: > > > > a) This list should be built by the snooping switch sending > > Multicast Router Solicitation messages as described in IGMP > > Multicast Router Discovery [MRDISC]. It may also snoop > > Multicast Router Advertisement messages sent by and to other > > nodes. > > > > b) The arrival port for IGMP Queries (sent by multicast routers) > > where the source address is not 0.0.0.0. > > > > The 0.0.0.0 address represents a special case where the switch > > is proxying IGMP Queries for faster network convergence, but is > > not itself the Querier. The switch does not use its own IP > > address (even if it has one), because this would cause the > > Queries to be seen as coming from a newly elected Querier. The > > 0.0.0.0 address is used to indicate that the Query packets are > > NOT from a multicast router. > > > > c) Ports explicitly configured by management to be IGMP-forwarding > > ports, in addition to or instead of any of the above methods to > > detect router ports. > > > > 2) IGMP networks may also include devices that implement "proxy- > > reporting", in which reports received from downstream hosts are > > summarized and used to build internal membership states. Such > > proxy-reporting devices may use the all-zeros IP Source-Address > > when forwarding any summarized reports upstream. For this reason, > > IGMP membership reports received by the snooping switch must not > > be rejected because the source IP address is set to 0.0.0.0. > > > > -Thanks > > > _______________________________________________ > > discuss mailing list > > discuss@openvswitch.org > > http://openvswitch.org/mailman/listinfo/discuss > > > > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
