Re: [magma] Questions with IGMP Snooping

Marshall Eubanks <marshall.eubanks@gmail.com> Fri, 17 December 2004 15:12 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26096; Fri, 17 Dec 2004 10:12:34 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfJvA-0007lS-2r; Fri, 17 Dec 2004 10:21:33 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfJeH-0003uN-OO; Fri, 17 Dec 2004 10:04:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfJUE-0007WL-2Y for magma@megatron.ietf.org; Fri, 17 Dec 2004 09:53:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23950 for <magma@ietf.org>; Fri, 17 Dec 2004 09:53:40 -0500 (EST)
Received: from rproxy.gmail.com ([64.233.170.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfJcp-00078k-9S for magma@ietf.org; Fri, 17 Dec 2004 10:02:38 -0500
Received: by rproxy.gmail.com with SMTP id a36so1830813rnf for <magma@ietf.org>; Fri, 17 Dec 2004 06:53:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=IpqYngDCAiUpMc/1UZF1sGzoIQHYGftIapWfL/dfzKQHfoiO5EH7a/jHFokbeVwkueDGkPSb/Ktzvwst4JgM7VUfgxusOf1jmX1eGM9bKm+uQPg+NbkWtDDDGgBQDcp7TPVeX7B6wwAIurRFD33H4lTqq21r9xHtzKaRz3jc9hE=
Received: by 10.38.83.77 with SMTP id g77mr270385rnb; Fri, 17 Dec 2004 06:53:36 -0800 (PST)
Received: by 10.38.208.48 with HTTP; Fri, 17 Dec 2004 06:53:36 -0800 (PST)
Message-ID: <dcad22d8041217065333e04d20@mail.gmail.com>
Date: Fri, 17 Dec 2004 09:53:36 -0500
From: Marshall Eubanks <marshall.eubanks@gmail.com>
To: "Bryan McLaughlin (brmclaug)" <brmclaug@cisco.com>
Subject: Re: [magma] Questions with IGMP Snooping
In-Reply-To: <85198C3A00F7664B87A81BF35767668D832E35@xmb-ams-334.emea.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
References: <85198C3A00F7664B87A81BF35767668D832E35@xmb-ams-334.emea.cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Content-Transfer-Encoding: 7bit
Cc: magma@ietf.org
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Marshall Eubanks <marshall.eubanks@gmail.com>
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
Sender: magma-bounces@ietf.org
Errors-To: magma-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Content-Transfer-Encoding: 7bit

Hello;

Beau Williamson's Book (Developing IP Multicast Networks, Vol I),
covers this fairly intensively
in Chapter 14, for IGMP v1 and v2. The big difference here for v3 is
that (4.2.14 from RFC 3376)

   Version 3 Reports are sent with an IP destination address of
   224.0.0.22, to which all IGMPv3-capable multicast routers listen.  A
   system that is operating in version 1 or version 2 compatibility
   modes sends version 1 or version 2 Reports to the multicast group
   specified in the Group Address field of the Report.  In addition, a
   system MUST accept and process any version 1 or version 2 Report
   whose IP Destination Address field contains *any* of the addresses
   (unicast or multicast) assigned to the interface on which the Report
   arrives.

So v3 IGMP membership reports are associated with a specific MAC
address, whereas v1 and v2
IGMP reports are sent along with the (typically much higher data rate)
multicast group traffic using the group MAC address. Thus it is much
easier to filter out the IGMP v3 traffic.

On Thu, 16 Dec 2004 17:34:15 +0100, Bryan McLaughlin (brmclaug)
<brmclaug@cisco.com> wrote:
>  
> Keerthi 
>   
> Inline 
>   
> ________________________________
>  From: magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] On Behalf Of
> keerthi.jayaram@wipro.com
> Sent: 16 December 2004 13:27
> To: magma@ietf.org
> Subject: [magma] Questions with IGMP Snooping
> 
>  
>  
> Hello, 
> I have the following doubt regarding IGMP Snooping. 
>   
> 1)Once the IGMP Snooping is completed and a mapping is done between the IP
> multicast Address and the MAC Multicast address, will the switch with the
> IGMP Snooping code also snoop the Multicast IP packets coming from the
> Multicast router to the switch? 
> [BMc>] a snooping switch will look at IGMP packets only. 
>   

What Bryan means is that the Switch CPU should look at IGMP packets only;
to do this, it is not enough to look at the Ethernet MAC address in
IGMP v1 / v2, but also the IP header.
Beau describes why you really don't want to do IP header inspection in
the CPU, but lower
down in the switching engine. This is not a problem for v3.

The real trouble here, of course, is the still paltry deployment of IGMP v3. 

>  I am asking this because that the Multicast IP packets will contain the IP
> multicast address and how will the switch(which is a layer 2 device) know
> the IP Multicast address for the data coming to the switch? 
> [BMc>]  Snooping is done to look for IGMP reports. IGMP is protocol 2, so
> easily identified by the switch . A router will receive all IPmc data
> streams anyway, unless PIM snooping is used. 
>   

I would add that the mapping between Group address and MAC addresses
is crucial here.
It disturbs me that there is at least one I-D 
which seem to break this mapping for no good reason that I can see.
(I specifically refer to
http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-03.txt, which
is
Standards Track and seems to only restrict multicast MAC addresses in
ULE to the Ethernet standard
of having the first bit set to one.)

Marshall



>   
> 2)Will IGMP snooping not work on a switch which does not have a VLAN
> configured to it and instead has just LAN setup?
> [BMc>]  
> IGMP snooping is no limited by or to Vlans.  
>   
> Bryan 
>  
> Thanks in advance, 
> regards 
> Keerthi 
> _______________________________________________
> magma mailing list
> magma@ietf.org
> https://www1.ietf.org/mailman/listinfo/magma
> 
> 
>

_______________________________________________
magma mailing list
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma