From: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Philip Downey <pdowney@Brocade.com>,
David Miller <davem@davemloft.net>,
"kuznet@ms2.inr.ac.ru" <kuznet@ms2.inr.ac.ru>,
"jmorris@namei.org" <jmorris@namei.org>,
"yoshfuji@linux-ipv6.org" <yoshfuji@linux-ipv6.org>,
"kaber@trash.net" <kaber@trash.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH] IGMP: Inhibit reports for local multicast groups
Date: Thu, 13 Aug 2015 15:08:09 -0300 [thread overview]
Message-ID: <20150813180809.GB22268@indiana.gru.redhat.com> (raw)
In-Reply-To: <20150813170137.GE32627@lunn.ch>
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.
next prev parent reply other threads:[~2015-08-13 18:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 16:13 [PATCH] IGMP: Inhibit reports for local multicast groups Philip Downey
2015-08-12 23:45 ` David Miller
2015-08-13 14:48 ` Philip Downey
2015-08-13 16:06 ` Andrew Lunn
2015-08-13 16:52 ` Philip Downey
2015-08-13 17:01 ` Andrew Lunn
2015-08-13 18:08 ` Thadeu Lima de Souza Cascardo [this message]
2015-08-14 8:55 ` Philip Downey
2015-08-14 8:56 ` Philip Downey
2015-08-14 13:35 ` Andrew Lunn
2015-08-14 14:36 ` Philip Downey
[not found] <1>
2015-08-24 11:39 ` Philip Downey
2015-08-25 21:20 ` David Miller
2015-08-26 9:23 ` Philip Downey
2015-08-27 15:46 ` Philip Downey
2015-08-28 20:29 ` David Miller
2015-08-28 21:19 ` Cong Wang
2015-08-31 10:33 ` Philip Downey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150813180809.GB22268@indiana.gru.redhat.com \
--to=cascardo@redhat.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pdowney@Brocade.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).