Sorry for the duplication - I responded in a similar manner before seeing this.
Thanks Philip > -----Original Message----- > From: Thadeu Lima de Souza Cascardo [mailto:casca...@redhat.com] > Sent: Thursday, August 13, 2015 7:08 PM > To: Andrew Lunn > Cc: Philip Downey; David Miller; kuz...@ms2.inr.ac.ru; jmor...@namei.org; > yoshf...@linux-ipv6.org; ka...@trash.net; linux-ker...@vger.kernel.org; > netdev@vger.kernel.org > Subject: Re: [PATCH] IGMP: Inhibit reports for local multicast groups > > On Thu, Aug 13, 2015 at 07:01:37PM +0200, Andrew Lunn wrote: > > On Thu, Aug 13, 2015 at 04:52:32PM +0000, Philip Downey wrote: > > > Hi Andrew > > > IGMP snooping is designed to prevent hosts on a local network from > receiving traffic for a multicast group they have not explicitly joined. > Link- > Local multicast traffic should not have an IGMP client since it is reserved > for > routing protocols. One would expect that IGMP snooping needs to ignore > local multicast traffic in the reserved range intended for routers since there > should be no IGMP client to make "join" requests. > > > > The point of this patch is that Linux is sending out group membership > > for these addresses, it is acting as a client. What happens with a > > switch which is applying IGMP snooping to link-local multicast groups? > > You turn on this feature, and you no longer get your routing protocol > > messages. > > > > I had a quick look at RFC 3376. The only mention i spotted for not > > sending IGMP messages is: > > > > The all-systems multicast address, 224.0.0.1, is handled as a special > > case. On all systems -- that is all hosts and routers, including > > multicast routers -- reception of packets destined to the all-systems > > multicast address, from all sources, is permanently enabled on all > > interfaces on which multicast reception is supported. No IGMP > > messages are ever sent regarding the all-systems multicast address. > > > > IGMP v2 has something similar: > > > > The all-systems group (address 224.0.0.1) is handled as a special > > case. The host starts in Idle Member state for that group on every > > interface, never transitions to another state, and never sends a > > report for that group. > > > > But i did not find anything which says all other link-local addresses > > don't need member reports. Did i miss something? > > > > Andrew > > From RFC 4541 (Considerations for Internet Group Management Protocol > (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches): > > 2) Packets with a destination IP (DIP) address in the 224.0.0.X range > which are not IGMP must be forwarded on all ports. > > This recommendation is based on the fact that many host systems do > not send Join IP multicast addresses in this range before sending > or listening to IP multicast packets. Furthermore, since the > 224.0.0.X address range is defined as link-local (not to be > routed), it seems unnecessary to keep the state for each address > in this range. Additionally, some routers operate in the > 224.0.0.X address range without issuing IGMP Joins, and these > applications would break if the switch were to prune them due to > not having seen a Join Group message from the router. > > So, it looks like some hosts and routers out there in the field do not send > joins for those local addresses. In fact, IPv4 local multicast addresses are > ignored when Linux bridge multicast snooping adds a new group. > > static int br_ip4_multicast_add_group(struct net_bridge *br, ... > if (ipv4_is_local_multicast(group)) > return 0; > > Cascardo. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
