[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
mcohort: Re: IGMPv3 & HP 4000 switches
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 : jad@ns.uoregon.edu
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)
-------------------------------------------------------------------
Archive: http://darkwing.uoregon.edu/~llynch/mcastwks/mcohort/
sub/unsub: http://darkwing.uoregon.edu/~llynch/mcastwks/mcohort.html