All things related to multicast

[Brent Sweeny <>]

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