Skip to Content.
Sympa Menu

wg-multicast - Re: survey forwarded from ag-tech/beacon lists

Subject: All things related to multicast

List archive

Re: survey forwarded from ag-tech/beacon lists


Chronological Thread 
  • From: Dan Pritts <>
  • To: Caren Litvanyi <>
  • Cc:
  • Subject: Re: survey forwarded from ag-tech/beacon lists
  • Date: Mon, 7 Mar 2005 18:11:28 -0500

On Mon, Mar 07, 2005 at 04:53:22PM -0500, Caren Litvanyi wrote:
> interesting responses, but I was not really able to incorporate
> the issues raised in any troubleshooting that we teach as part of
> the I2 multicast hands-on workshops. They seemed somewhat vendor-
> specific, with the only solution being to recommend a different
> vendor. We stay away from vendor advice or bashing as best we can
> in our workshops.

At the time, I gave specific suggestions for how to make multicast work
(more or less well) in an HP switch environment. I gave a few gotchas
and suggestions on how to work around them. My note is at:

https://mail.internet2.edu/wws/arc/wg-multicast/2004-09/msg00011.html

It looks like my ascii network drawing got munged in the archive. The
"downstairs switch" is connected to the "core switch," not to the router.

I also sent a quick note on the Dell 3024:

https://mail.internet2.edu/wws/arc/wg-multicast/2004-09/msg00012.html

I agree that you should not "vendor bash" in these workshops. When I took
the workshop, you weren't an instructor, but it had very specific advice
for using Cisco & Juniper routers. I don't think that you can in any
reasonable way "stay away from vendor advice" when giving the workshop -
the hands-on nature of it is just as important as the fundamentals of
how PIM and MSDP work.

Perhaps you meant "stay away from advice on which vendors to use"
rather than "stay away from advice on making each vendor's stuff work."

But in an environment where some vendors work, some flat out don't, and
others need to be treated with proper care & feeding, specific advice
on different vendors is invaluable.

It is not bashing a vendor to say that, for instance, Vendor N has a
non-standard compliant implementation of IGMPv3 snooping that causes it
to not interact with IGMPv1 & IGMPv2 - so you shouldn't try to do IGMPv3
if you use Vendor N's switches (unless you have no IGMPv1/2 devices).

Nor is it bashing to say that one of Vendor D's first switches crashed
if you turned on igmp snooping and had any significant amount of traffic
on your network.

Nor is it bashing to say that Vendor X's "switches" come with PIM enabled
and turning one on on your network (thinking of it as a layer-2 device)
without disabling PIM routing may break multicast (at least it did for
me once).

Nor to say that Vendor H basically works but definitely has issues.

Nor is it bashing to say that old cisco switches flat out don't support
IGMP snooping so don't be surprised when multicast floods on your network
when you switch from a CGMP-speaking cisco router to a juniper.

When I took the workshop, the only advice i got on making IGMP snooping
work was "it doesn't. Use dedicated vlans for multicast."

My experience is that it does with many vendors, but it's an edge case
and is often buggy.

This makes having specific information in the workshop, and on this
mailing list, all the more important.

danno
--
dan pritts - systems administrator - internet2
734/352-4953 office 734/834-7224 mobile



Archive powered by MHonArc 2.6.16.

Top of Page