Hi,One problem you may

JMoon92382 · ‎07-31-2015

Hello,

Trying to set up a multicast to go across the same vlan (239) on 2 different Catalyst 3850 switches. They are connected via a trunk port on g1/0/1. I would like to make sure that multicast only goes on vlan 239, and no other vlan. Thanks for your help

Peter Paluch · ‎07-31-2015

Hello,

Generally, the simplest way would be to make sure that no router or a routing-enabled multilayer switch that is connected to VLAN 239 has PIM/IGMP activated on its interface in this VLAN. Simply put, make sure that there are no commands starting with ip pim ... on routed interfaces in VLAN 239. Without PIM and IGMP (which are started using ip pim ... commands), a routed interface does not participate in multicast routing. That should make your VLAN 239 inaccessible for multicasts in other VLANs.

Best regards,
Peter

Steve Fuller · ‎07-31-2015

Hi,

One problem you may encounter with this configuration is that IGMP snooping may result in traffic destined to your receivers being dropped by the switch.

As per the IGMP Snooping section of the Catalyst 3850 configuration guide:

Layer 2 devices can use IGMP snooping to constrain the flooding of multicast traffic by dynamically configuring Layer 2 interfaces so that multicast traffic is forwarded to only those interfaces associated with IP multicast devices. As the name implies, IGMP snooping requires the LAN device to snoop on the IGMP transmissions between the host and the router and to keep track of multicast groups and member ports.

This feature requires that some device i.e., a router, send a periodic IGMP Membership Query message that the receivers would respond to with an IGMP Membership Report message. The switch "snoops" the IGMP response and thus learns which switch ports have multicast receivers connected, and which multicast groups they wish to receive.

If you have no PIM router configured then you will typically need to configure an "IGMP snooping querier" which takes care of periodically sending the IGMP Membership Query. The details of this can be found in the Configuring the IGMP Snooping Querier (CLI) section of the configuration guide.

Regards

Peter Paluch · ‎07-31-2015

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

Steve Fuller · ‎07-31-2015

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

Peter Paluch · ‎07-31-2015

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

Steve Fuller · ‎07-31-2015

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

Joseph W. Doherty · ‎07-31-2015

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.

Steve Fuller · ‎07-31-2015

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

Joseph W. Doherty · ‎07-31-2015

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

Setting up Multicast on same VLAN