Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1207422

RE: [PATCH] IGMP: Inhibit reports for local multicast groups

From Philip Downey <pdowney@Brocade.com>
Newsgroups linux.kernel
Subject RE: [PATCH] IGMP: Inhibit reports for local multicast groups
Date 2015-08-14 11:00 +0200
Message-ID <pXj0e-5AB-5@gated-at.bofh.it> (permalink)
References (2 earlier) <pX1Zo-6gD-35@gated-at.bofh.it> <pX3ou-8pv-17@gated-at.bofh.it> <pX41c-Hx-15@gated-at.bofh.it> <pX4aR-18m-1@gated-at.bofh.it> <pX56V-2ug-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Sorry for the duplication - I responded in a similar manner before seeing this.

Thanks

Philip

> -----Original Message-----
> From: Thadeu Lima de Souza Cascardo [mailto:cascardo@redhat.com]
> Sent: Thursday, August 13, 2015 7:08 PM
> To: Andrew Lunn
> Cc: Philip Downey; David Miller; 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
> 
> 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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] IGMP: Inhibit reports for local multicast groups Philip Downey <pdowney@brocade.com> - 2015-08-12 18:20 +0200
  Re: [PATCH] IGMP: Inhibit reports for local multicast groups David Miller <davem@davemloft.net> - 2015-08-13 01:50 +0200
    RE: [PATCH] IGMP: Inhibit reports for local multicast groups Philip Downey <pdowney@Brocade.com> - 2015-08-13 16:50 +0200
      Re: [PATCH] IGMP: Inhibit reports for local multicast groups Andrew Lunn <andrew@lunn.ch> - 2015-08-13 18:20 +0200
        RE: [PATCH] IGMP: Inhibit reports for local multicast groups Philip Downey <pdowney@Brocade.com> - 2015-08-13 19:00 +0200
          Re: [PATCH] IGMP: Inhibit reports for local multicast groups Andrew Lunn <andrew@lunn.ch> - 2015-08-13 19:10 +0200
            Re: [PATCH] IGMP: Inhibit reports for local multicast groups Thadeu Lima de Souza Cascardo <cascardo@redhat.com> - 2015-08-13 20:10 +0200
              RE: [PATCH] IGMP: Inhibit reports for local multicast groups Philip Downey <pdowney@Brocade.com> - 2015-08-14 11:00 +0200
            RE: [PATCH] IGMP: Inhibit reports for local multicast groups Philip Downey <pdowney@Brocade.com> - 2015-08-14 11:00 +0200
              Re: [PATCH] IGMP: Inhibit reports for local multicast groups Andrew Lunn <andrew@lunn.ch> - 2015-08-14 15:50 +0200
                RE: [PATCH] IGMP: Inhibit reports for local multicast groups Philip Downey <pdowney@Brocade.com> - 2015-08-14 16:40 +0200

csiph-web