From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752783AbbH1U3K (ORCPT ); Fri, 28 Aug 2015 16:29:10 -0400 Received: from shards.monkeyblade.net ([149.20.54.216]:55668 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751965AbbH1U3I (ORCPT ); Fri, 28 Aug 2015 16:29:08 -0400 Date: Fri, 28 Aug 2015 13:29:07 -0700 (PDT) Message-Id: <20150828.132907.1853637831762392208.davem@davemloft.net> To: pdowney@brocade.com Cc: kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@trash.net, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH] IGMP: Inhibit reports for local multicast groups From: David Miller In-Reply-To: <6112e6ccb97c5015b6f8125d8c0f75c179b53198.1440689853.git.pdowney@brocade.com> References: <1> <6112e6ccb97c5015b6f8125d8c0f75c179b53198.1440689853.git.pdowney@brocade.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 28 Aug 2015 13:29:08 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Philip Downey Date: Thu, 27 Aug 2015 16:46:26 +0100 > The range of addresses between 224.0.0.0 and 224.0.0.255 inclusive, is > reserved for the use of routing protocols and other low-level topology > discovery or maintenance protocols, such as gateway discovery and > group membership reporting. Multicast routers should not forward any > multicast datagram with destination addresses in this range, > regardless of its TTL. > > Currently, IGMP reports are generated for this reserved range of > addresses even though a router will ignore this information since it > has no purpose. However, the presence of reserved group addresses in > an IGMP membership report uses up network bandwidth and can also > obscure addresses of interest when inspecting membership reports using > packet inspection or debug messages. > > Although the RFCs for the various version of IGMP (e.g.RFC 3376 for > v3) do not specify that the reserved addresses be excluded from > membership reports, it should do no harm in doing so. In particular > there should be no adverse effect in any IGMP snooping functionality > since 224.0.0.x is specifically excluded as per RFC 4541 (IGMP and MLD > Snooping Switches Considerations) section 2.1.2. Data Forwarding > Rules: > > 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. > > IGMP reports for local multicast groups can now be optionally > inhibited by means of a system control variable (by setting the value > to zero) e.g.: > echo 0 > /proc/sys/net/ipv4/igmp_link_local_mcast_reports > > To retain backwards compatibility the previous behaviour is retained > by default on system boot or reverted by setting the value back to > non-zero e.g.: > echo 1 > /proc/sys/net/ipv4/igmp_link_local_mcast_reports > > Signed-off-by: Philip Downey Applied to net-next, thanks.