Hi Steve,

Good point. You may be interested to know that switches with IGMP Snooping actually fall back to multicast flooding mode if no multicast-enabled router is found on a network (determined by listening to PIM Hello and IGMP Membership Query messages) and no IGMP Snooping Querier is configured on the switch. This way, even switches with IGMP Snooping active should not impact multicast delivery within a VLAN if there is no multicast router present.

Best regards,
Peter

Thanks Peter.

Do you have any reference or documentation that shows that IGMP snooping switches fall back to flooding multicast traffic in the absence of a multicast enabled router? This is not something I've come across, and indeed the TechNote Multicast Does Not Work in the Same VLAN in Catalyst Switches seems to indicate the opposite. I appreciate the TechNote is from 2006, but I've not found any more recent documents that indicate the fall back mechanism you describe.

The above point aside, I think we'd consider the flooding of multicast traffic as undesirable, and so would want IGMP snooping to constrain the traffic to ports with receivers connected. One way of achieving that, and still ensuring multicast traffic does not "leak" beyond the VLAN as stated by the OP would be to configure the IGMP snooping querier.

Regards

Steve,

Do you have any reference or documentation that shows that IGMP snooping switches fall back to flooding multicast traffic in the absence of a multicast enabled router?

No docs but I've done debugs a few months ago on Catalyst 2950 and 2960 series.

When the first mrouter port on an IGMP Snooping-enabled switch is identified, the debugs read:

*Mar  1 00:10:22.854: Pvmp Gi0/1, VLAN 1, FWDing
*Mar  1 00:10:22.854: IGMPSN: mgt: Reverting flood mode to only multicast router ports for Vlan 1.
*Mar  1 00:10:22.862: IGMPSN: Adding router port Gi0/1 to all GCEs in Vlan 1
*Mar  1 00:10:22.862: IGMPSN: added rport Gi0/1 on Vlan 1
*Mar  1 00:10:24.850: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
*Mar  1 00:10:25.857: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up

After the last mrouter port is lost, debugs read:

*Mar  1 00:11:06.122: Pvmp Gi0/1, VLAN 1, not FWDing
*Mar  1 00:11:06.122: IGMPSN: mgt: deleted rport Gi0/1 on Vlan 1
*Mar  1 00:11:06.122: IGMPSN: Deleting router port Gi0/1 to all GCEs in Vlan 1
*Mar  1 00:11:06.122: IGMPSN: mgt: Setting flood mode to all ports in Vlan 1
*Mar  1 00:11:06.122: IGMPSN: mgt: Vlan 1, port Gi0/1 port_id 25 in non-fwd mode
*Mar  1 00:11:07.120: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down
*Mar  1 00:11:08.119: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

Similarly, when no mrouter port is identified and the IGMP Snooping Querier feature is activated, the debugs read:

*Mar  1 00:20:07.657: IGMPQR: vlan_id 1: leaving Disabled state and entering Querier state
*Mar  1 00:20:07.665: IGMPQR: vlan_id 1: timer GQ_PIM Timer expired in Querier state
*Mar  1 00:20:07.665: (l2mcsn_flood_l2mc_pak) IGMPSN flood pak to vlan 1
*Mar  1 00:20:07.665: IGMPSN: router: Vlan 1:  received Query from IGMP querier
*Mar  1 00:20:07.665: IGMPSN: Received SVI query(224.0.0.1) on vlan 1
*Mar  1 00:20:07.665: IGMPSN: IGMP general queries received on Vlan 1 updates all groups
*Mar  1 00:20:07.665: IGMPSN: timer: start report_timer 2500 msecs of vlan 1
*Mar  1 00:20:07.665: IGMPSN: Adding iquerier flag in vlan 1
*Mar  1 00:20:07.665: IGMPSN: mgt: Reverting flood mode to only multicast router ports for Vlan 1.
*Mar  1 00:20:07.665: IGMPSN: router: iquerier added on Vlan 1

After the IGMP Snooping Querier feature is deactivated and the internal iquerier flag is cleared (the iquerier flag is not described anywhere but according to my observations, it is a flag saying "I-am-Querier" which is set if the IGMP Snooping Querier feature is activated and, at the same time, the switch has the right to become an IGMP Querier based on normal IGMP Querier election rules; the iquerier flag is cleared 5 minutes after the conditions above stop being met), the debugs resemble those when the last mrouter port is lost - I did not record them but I recall seeing an absolutely identical behavior.

That being said, I absolutely agree that this behavior may be platform-specific.

The above point aside, I think we'd consider the flooding of multicast traffic as undesirable, and so would want IGMP snooping to constrain the traffic to ports with receivers connected. One way of achieving that, and still ensuring multicast traffic does not "leak" beyond the VLAN as stated by the OP would be to configure the IGMP snooping querier.

Steve, the IGMP Snooping optimizes multicast delivery within a VLAN, not between VLANs. Regardless of IGMP Snooping being active or not, multicast will never leak from one VLAN to another. For that to happen, there must be a multicast-enabled router connected to both VLANs, and it must make the choice of routing the multicast from one VLAN into the other.

Best regards,
Peter

Hi Peter,

Thanks for the confirmation and the debugs. I'll try similar on other platforms when I have a chance.

Steve, the IGMP Snooping optimizes multicast delivery within a VLAN, not between VLANs. Regardless of IGMP Snooping being active or not, multicast will never leak from one VLAN to another. For that to happen, there must be a multicast-enabled router connected to both VLANs, and it must make the choice of routing the multicast from one VLAN into the other.

I understand that IGMP snooping is to constrain traffic within a VLAN and that we need PIM to route multicast between VLANs. My point was that the OP didn't want multicast traffic sourced in his VLAN 239 reaching any other VLAN, and you'd recommended to remove ip pim ... for any routed interfaces in VLAN 239. That's fine, but as we see, leads to flooding. The point was that enabling ip igmp snooping querier we would constrain the multicast traffic within the VLAN and there would be no way it would be routed out of the VLAN.

Regards

Steve, I too took "One way of achieving that, and still ensuring multicast traffic does not "leak" beyond the VLAN as stated by the OP would be to configure the IGMP snooping querier." as implying, without an IGMP snooping querier, multicast would flood beyond the VLAN.  As Peter noted, that's not the case.

Your later posting with "The point was that enabling ip igmp snooping querier we would constrain the multicast traffic within the VLAN and there would be no way it would be routed out of the VLAN." still might be read as the ip igmp snooping querier has something to do with restricting routing multicast from leaving the VLAN.  Well, yes it would, if it blocks multicast from reaching the router's port.  But even if it doesn't, a router won't forward (or leak) multicast traffic unless it's has been configured to do so.  (A perfect example would be a router and other multicast hosts connected to a hub.)

If you've just meant to say it would be better to have IGMP snooping, which requires a IGMP querier, yup, agree.

Hi Joesph,

If you've just meant to say it would be better to have IGMP snooping, which requires a IGMP querier, yup, agree.

That's exactly what I was trying to say all along. Thanks for putting into concise, plain english.

Regards

Oh, that is interesting!  If you didn't enable a querier, I had thought you would need to disable IGMP snooping.