Subject: [magma] Re: IGMPv3 & HP 4000 switches

From: Toerless Eckert <[email-masked]>
Date: Thu, 27 Jun 2002 21:31:02 -0700

On Thu, Jun 27, 2002 at 08:32:44PM -0700, 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. 

If you have a network with 10Mbps, the amount of unwanted multicast
traffic may be to much to bear for some host. After all, avoiding this 
is the purpose of IGMP Snooping !

> 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.

CGMP actually works together with IGMPv3, it just doesn't constrain
unwanted traffic as well as IGMP Snooping enabled for IGMPv3 could.
See the documentation on IGMPv3 in IOS.

Cheers
	Toerless

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Nitin jain <[email-masked]>
Date: Thu, 27 Jun 2002 20:32:44 -0700

Hi Lucy,

Please elaborate the case that would break. Thanks.

Nitin

At 01:28 PM 6/27/02 -0700, Lucy E. Lynch wrote:
>All -
>
>As you may already know, we've uncovered a problem with IGMPv3 and HP
>4000m series switches. The condensed version is that in order to use
>SSM/IGMPv3 on a sub-net with an HP 4000 in the path IGMP snooping MUST be
>turned off in the switch.
>
>see:
>http://archives.internet2.edu/guest/archives/wg-multicast/log200206/msg0003
8.html
>
>José Domínguez, our senior network engineer here at the UO, has tried to
>pursue this with HP but the results are a bit frustrating. HP is
>discontinuing the 4000 series switches by early next year and has no plans
>to address IGPMv3 related problems since there is not an IETF RFC for same
>(their proposed solution is to upgrade to new gear). We've turned off
>snooping on at least one switch here to deal with testing issues - but
>this isn't a solution that will work for everyone. If you have similar
>issues on your campus - or if you own HP gear, please contact me as we
>would like to be able to escalate this issue with HP and more is better...
>
>Lucy E. Lynch 				Academic User Services
>Computing Center			University of Oregon
>[email-masked]		(541) 346-1774/Cell: 912-7998
>

---

From: José A. Domínguez <[email-masked]>
Date: Thu, 27 Jun 2002 22:03:02 -0700 (PDT)

> 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?

> 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   : [email-masked]
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)

---

From: Nitin jain <[email-masked]>
Date: Fri, 28 Jun 2002 10:23:25 -0700

Hi Jose,

  Please see my responses:

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

  We'd prefer not to change the behaviour of the end system. It might be
easier to adapt the  switches to learn from either of the v1/v2/v3 reports
based on specific implementations.

>layer device. Can the CPU and switch architecture keep up with this?

  This is implementation specific, but certainly feasible.
>systems and routers should be the ones enforcing what makes it up the 

Yes,  it would be better if it were done at the router instead. We can't
have receivers with overlapping INCLUDE/EXCLUDE within the same subnet. 
  
>unless you really want to receive it. 

   Agreed. 
>Sorry, if you already do ...

   Foundry currently does not support the IGMPv3, but it is in our plans. 

   Regards,

Nitin

---

From: Bill Fenner <[email-masked]>
Date: Sun, 30 Jun 2002 14:43:40 -0700

One option that nobody has mentioned is to downgrade to IGMPv2 on the
router, allowing the snooping to continue using the protocol it knows
about.

  Bill

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 30 Jun 2002 15:32:47 -0700

> router, allowing the snooping to continue using the protocol it knows

Well, i mentioned this in the initial mails i had with UOregon, and
this is exactly the reason why IOS still defaults to IGMPv2 (as documented).
I think the point with Oregon was that they wanted to start enabling SSM,
right ?

Cheers
	Toerless