IGMPv3 Join/Leave Messages, IGMP Filtering, and a 3750

[mfarrenkopf]

On a 3750 switch, IOS 12.2(25)SEE2 (also 12.2(53)SE1, to which we're slowly moving), IP Services feature set.  Routed Layer 3 access.

We're looking at implementing IGMP v3 in our standard configuration.  The documentation says that IGMP v3 join/leave messages are not supported when IGMP filtering is on.  What is the back story on this?  I understand IGMP filtering (allowing or disallowing certain multicast addresses or multicast address ranges or restricting the number of multicast groups as per http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/configuration/guide/swigmp.html#wp1117317).  But I don't understand why this impacts IGMPv3.  It doesn't seem like the two should be incompatible, so I'm at a loss to explain why it's not possible for the two to co-exist.  I also can't explain to my colleagues why having IGMP filtering on but unconfigured doesn't impact IGMPv1 or IGMPv2.  The 3750 defaults to IGMP filtering on but nothing configured.

We don't use IGMP filtering right now, so it's easy to shut off.  But I'd like to understand so that I could speak intelligently about it if we ever did feel a need for it.  I would welcome explanations, pointers to other documentation, other books, etc.

Thanks,

Matt

[Giuseppe Larosa]

Hello Matt,

IGMPv3 is source specific so it provides a Join for (group G and include source S ) or for (Group G and exclude source S1).

The IGMP filtering command syntax shows the use of address range that specifies multicast addresses only (one or a range)

Also the IGMPv3 Join packet is different then an IGMPv2 Join packet different header and different fields in the message.

The IGMP filtering implementation is probably hard coded to inspect only IGMPv2/IGMPv1 messages so the advice that it cannot support/inspect IGMPv3 messages.

The default behavior may be like that of a non existing ACL: if no address range is defined the feature allows all 224.0.0.0/4 multicast addresses

Hope to help

Giuseppe

[mfarrenkopf]

Hi Giuseppe,

Thanks for taking the time to reply!

I did understand that IGMPv3 is source-specific, but I didn't see why that should necessarily preclude filtering particular multicast addresses.  If I don't want a client receiving a multicast stream, it seemed reasonable that I should still be able to specify that client X can or cannot have the stream in any way by using filters.

I would agree that it sounds more like a case of either the hardware or software simply not supporting filtering on IGMPv3 join/leave messages.  Would you agree that there is no technical reason (i.e. nothing inherent in the IGMPv3 spec) why it couldn't be allowed?  It's just that the 3750 is missing a hardware or software component that won't allow it to do filtering using IGMPv3?  That's the way I'm reading your response.

Thanks,

Matt