All things related to multicast

[Alan Crosswell <>]

Paul,

Thanks for your reply.  Since your reply got forwarded to the list, I thought I 
would share some comments with you and the list.

-------- Original Message --------
Subject: Re: some IGMP snooping switch evaluations
Date: Thu, 27 Jan 2005 10:23:28 -0500
From: Brent Sweeny 
<>
To: 

References: 
<>

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.

According to the MAGMA snooping draft 
(http://www1.ietf.org/internet-drafts/draft-ietf-magma-snoop-11.txt) while it is 
*permissible* to flood groups for which there is no registered interest to all 
ports, it is better not to flood them and to only send them to the mrouter 
ports.  See item 3 on page 6.
> 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).

The issue I saw for delayed flush that you do not address is that the soft state 
for the switch seemed to still expire before that of the router, resulting in 
what was working "right" -- with only the registered ports getting the traffic 
until the switch's soft state expired and it cleared the IGMP info.  Meanwhile 
the router had not yet pruned the group since it's soft state timer was still 
counting down, so the switch then flooded all ports with traffic for another 
minute or so until the router's soft state pruned the group.  This doesn't seem 
right.  I set the delay flush to 100 seconds which should have been enough but 
didn't seem to make a difference.  Perhaps you could look at this case in more 
detail and advise on what I did wrong, since the delayed flush feature seemed to 
be exactly what I was looking for.
> 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.
By selective forwarding, do you mean filtering on source?  I would settle for 
filtering on group working ala IGMPv2 support.  I would also settle on soft 
state timeout working correctly as discussed above.
> 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.

But do any of your switches recognize even ASM "leaves" under IGMPv3 (Change to 
include mode with a null source vs. Block Old Sources).  I guess this is kind of 
a meaningless question as there'd be no reason to run IGMP v3 on a LAN with 
these switches if they're never going to handle v3.

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

Dunno about this.  These Ciscos I am talking about are IGMP snooping switches, 
not CGMP.  I guess you are saying other switches in the same LAN may need to 
hear the V2 leave?  I think it's more like a branch in the code was missed as 
this V2 leave only happens on one model of Cisco and not another.
> 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.

Sorry, but this sounds more like a marketing term than a technical one.  I'd be 
happy to test a 3400 or 5300.  Do you want to loan me one?
> 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.

Ah, maybe this is what I did wrong.  I'll give it a try.
> 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