All things related to multicast

["Michael H. Lambert" <>]

Hmm...  I don't see MLDv2 mentioned...

Michael

On 27 Jan 2005, at 10:23, Brent Sweeny wrote:

> Steven Wallace asked me to forward Paul Congdon's response to Alan's
> excellent questions to this list.  Steven said that he was sure that
> Paul wanted the answers to be posted here.
> --
> Brent Sweeny            
>
>             812 / 855-5391
> Indiana University Information Technology/Abilene Network Operations
> PGP fingerprint = 0F 6B 7E 1D 3A AD F3 01  63 1E 2B B3 1E B1 FA 7F
>
> Begin forwarded message:
>
> > From: "Congdon, Paul T (ProCurve)" 
> > <>
> > Date: January 24, 2005 1:42:58 PM EST
> > To: 
> > <>
> > Cc: "Steven S. Wallace" <>, "Kimball, Karen E" 
> > <>
> > Subject: IGMP implementations on ProCurve
> >
> > Alan,
> >
> > Steven Wallace from IU forwarded me a link of yours that had some
> > questions about ProCurve implementations of IGMP Snooping.  After
> > reviewing the page and questions, we've generated the following
> > responses.  Nice summary page, by the way.
> >
> > You were testing the ProCurve 2626.  Unfortunately, this model is
> > perhaps our most limited switch with respect to IGMP snooping.  It 
> > does
> > not offer Data-Driven ("Smart") IGMP capability. Data-Driven IGMP
> > actually is NOT part of any IGMP snooping standards, but is an
> > enhancement we have included in our products.  Flooding "stale" or
> > "unjoined" multicasts is in fact the behavior the IGMP standards would
> > dictate.  The filtering provided by IGMP snooping is an optimization 
> > of
> > network resources.  Occasional flooding is not desirable, but it is 
> > not
> > considered incorrect behavior.  We believe it would be worse to
> > incorrectly filter traffic, so when faced with a situation where
> > flooding is unavoidable, we choose to provide connectivity.
> >
> > ProCurve's newly added feature, IGMP Delayed-Flush, hugely improves 
> > the
> > flooding behavior on non-Data-Driven switches like the 2626.  We were
> > glad to see that you enabled this feature. It cannot altogether fix 
> > the
> > lack of Data-Driven support. I.e, it cleans up latent forwarding well,
> > but cannot do anything about unsolicited forwarding (forwarding prior
> > to any joins).
> >
> > As for IGMPv3, to fully support it involves router-centric behavior
> > (requires selective forwarding at Layer 3, dependant upon IP-flows). 
> > We
> > are not aware of any L2 switches that fully implement this. Without 
> > the
> > specific L3-ish hardware support in the ASICs, we believe it is
> > important to at least recognize and process the v3 Joins.  This is the
> > current extent of our IGMPv3 support.
> >
> > So, to answer your questions more specifically:
> >
> > 1) Will HP be making IGMP v3 snooping work correctly on the 2626? 
> > When?
> >
> > The 2626 interworks with IGMPv3 as described above. However, it will
> > never fully support all of its unique capabilities, as will be the 
> > case
> > for most switches (Layer 2 devices).
> >
> >  2) Does IGMP v3 snooping work correctly on other HP ProCurve models?
> >
> > The primary difference between IGMP snooping capabilities on different
> > ProCurve models is related to the data-driven capability described
> > above.  The IGMPv3 support, as described above, is fairly consistent
> > across models.  Effectively, we recognize and process v3 Joins, but do
> > not have the hardware capability to perform the full source-specific
> > filtering in our current shipping models.
> >
> >  3) Why do both the HP and Cisco flood the group-specific query out 
> > all
> > ports? Shouldn't this only go to the ports currently joined to the
> > group? Does this matter?
> >
> > ProCurve should NOT flood the group-specific query out all ports-- 
> > only
> > the General Query. The Group-specific Query should only go out the 
> > port
> > where the Leave was received (We will look into this).
> >
> > As for Cisco, this may be intentional behavior to support CGMP (Cisco
> > Group Multicast Protocol), which requires some "breaking" of IGMP
> > rules.
> >
> > 4) Why does the Cisco pass along all v3 host membership reports 
> > instead
> > of just the one needed to keep the router happy? Does this matter?
> >
> > I believe extra forwarding is only "annoying" to downstream routers, 
> > but
> > not necessarily really bad. The IGMP standards recommend suppressing
> > Joins from recently joined groups, but other joins are expected to be
> > forwarded. This helps ALL routers understand which multicast groups 
> > are
> > active on the network and may need forwarding.
> >
> > 5) Why does the Cisco spoof an IGMP v2 Leave Group message toward the
> > router when in IGMP v3 mode?
> >
> > There is no IGMPv3 Leave. The IGMPv2 Leave is used instead. Perhaps
> > Cisco is using this as a means to tell other routers/switches to stop
> > forwarding the mcast group (because those devices don't do the
> > source-specific portions of IGMPv3).
> >
> >
> > We noticed that you did not include the "Data-Driven IGMP" feature in
> > the list of things to look for when selecting a switch.   We believe
> > this feature is very useful for many IP-Multicast environments.  We 
> > also
> > suggest you consider testing with other ProCurve models. The 3400 or
> > 5300 would be better for the type of testing you are doing.
> >
> > Finally, the "Immediate Leave" behavior you mentioned is another non-
> > standard enhancement that many vendors (including ProCurve) support.
> > However, on a non-Data-Driven switch such as the 2626 (which floods
> > unjoined groups), the FastLeave actually increases the opportunity for
> > flooding stale groups.  This is why FastLeave is disabled by default 
> > on
> > the ProCurve 2626.  You may want to experiment with this parameter in
> > your environment to avoid making any undesirable flooding worse.
> >
> > Thanks for your comments and review of the 2626.  Feel free to contact
> > me if you have further questions.
> >
> > Sincerely,
> >
> > Paul Congdon
> > ProCurve CTO and HP Fellow
> > ProCurve Networking by HP