All things related to multicast

[José A. Domínguez <>]

On Thu, 27 Jun 2002, Nitin jain wrote:

> Hi Lucy,
> 
>    I am curious why turning off the IGMP snooping should not work in every
> case. If that doesn't work, we should examine the case as the plain layer2
> switch/hub would also exhibit the same issue. 
> 

No, that's not the case. Turning off IGMP snooping off will solve the 
problem since it will flood multicast packets to all ports.

For IGMPv3 to work when using layer2 igmp snooping devices the end systems 
will have to work in compatibility mode, that is, they will have to send 
both igmpv3 and v2,v1 membership reports. In this case, the igmp snopping 
switch won't have to look into the igmpv3 membership report packet 
which is sent to 224.0.0.22 but will create the forwarding state because 
of the igmpv2/v1 report which is also sent to the group address.

Now I don't know how you can configure an end system to do both ... anyone 
knows how?

> I would think that this would be the case for any vendor that is not aware
> of IGMPv3 in the snooping implementation as IGMPv2 did not care about the
> source specificness. Therefore, plain layer2 forwarding would not be
> adequate for source specific joins, or exclude source. Thus, it would be
> advisable not to turn on any Layer 2 specific snooping, be it CGMP, IGMP
> etc. if the implementation is unaware of IGMPv3.
> 

As I said before the main problem is that membership reports in v3 are no 
longer sent to the multicast group address but to 224.0.0.22. This will 
obviously break all current igmpv2 snooping switches. If your igmp 
snooping switch would identify both membership reports sent to the 
multicast address and create the forwarding state and then treat 
224.0.0.22 as a special case where you would then look into the packet 
to create the forwarding state then it would all work great .... it would 
also mean that you no longer have a  simple layer2 device but a higher 
layer device. Can the CPU and switch architecture keep up with this?

In theory, one all devices are igmpv3 only, igmp snooping switches will be 
easier to implement. Just listen to packets whose destination is 
224.0.0.22 and you should be able to figure what's going on. 

Also, I'm not sure you want the switch enforcing the INCLUDE/EXCLUDE 
modes. You basically want a layer 2 device that snoops into membership 
reports to create the forwarding state. In the end the multicast packets 
will flow using as destination  the multicast group specified. End 
systems and routers should be the ones enforcing what makes it up the 
stack. 

> Please elaborate the case that would break. Thanks.
> 

The reason why Lucy said that you don't want to just turn off igmp 
snooping in all switches is due to our very own use of multicast. About 
40Mbps of continues traffic, is not something that you want going around 
unless you really want to receive it. 

How do Foundry deal with this? Do you guys have any plans to support it? 
Sorry, if you already do ...

BTW, if anyone can tell me that I'm going insane and that I shouldn't 
worry, that would be okay too ... ;-)


-- 
*********** NOTICE THE NEW PAGER  NUMBER ***********
José A. Domínguez           Voice   : +1.541.346.1685
Sr Network Engineer         VoIP    : +1.541.346.0267
Network Services Group      Cell    : +1.541.954.3678
Computing Center            Pager   : +1.888.788.2326
University of Oregon        Fax     : +1.541.346.4397
1225 Kincaid St.            Email   : 

Eugene, OR 97403-1212       PGP Keys: http://ns.uoregon.edu/~jad/pgp.keys
GPG Key ID: 0x98A02F16 (DA9A 9934 4010 9D78 6461  6C8C 8D84 AFBE 98A0 2F16)
PGP 2.6 ID: 0x7E3618B1 (DE 86 5B 94 E5 F9 40 08  95 57 1B 18 2E F5 85 47)