A good starting point will be the "show spanning-tree" command - check the status of the ports listed ensure that all the end user ports are listed as Type - "P2P Edge" - only uplinks should be Type "P2P". Enduser ports should be set as portfast edge ports with the command "spanning-tree portfast edge" - or even better, use the "spanning-tree portfast edge default" command to make all ports portfast / edge ports by default & then just configure Spanning tree on the uplinks where you want spanning tree working. This will prevent end users switching their PC's on and off from triggering network wide spanning-tree topology changes - which will cause multicast flooding.
"Show Spanning-tree detail" can be used to show the stability of spanning tree - this details the number of topology changes along with the time since last topology change for each VLAN configured - use this to check whether you have stabilized spanning tree.
There are lots of support posts on sorting out spanning-tree issues - so put the multicast flooding issue to one side at the moment & fix the spanning tree issue. Once that is fixed, multicast will probably be fixed too - you wont be able to fix the multicast flooding issue with an unstable spanning tree.
... View more
Hi, I have checked your capture and it shows spanning tree topology changes. Apply the following filter to Wireshark & you will see the BPDU's with the "TC" marker - fileter: stp.protocol == 0x0000
Ensure your user interfaces are configured as edge ports.
Figure out what is causing the topology changes - then the flooding will stop.
... View more
As I understand it, Sparse-Dense mode will operate in Sparse mode if there is a RP for the group - so if you create a RP in your Meraki environment, this (as per normal PIM-SM config) should be advertised to all multicast enabled routers - so this group will then become Sparse-Mode for the entire multicast domain. The question I have is why would you want to operate in Dense-mode rather than Sparse-mode? If there is no application / service reason, then I would test creating a PIM RP (at least 2 RP's - for resilience - with 2 BSR candidates to propogate RP information) & operating the service in Sparse-mode. If you need to continue to operate in Dense-Mode, then you will need to have a multicast boundary between the two environments to avoid it switching a network wide switch to Sparse-mode operation just for the group (assuming you scope the PIM RP accordingly).
... View more
We had an issue last week at a remote location. Every few minutes the IPTV system would pixilate for a few seconds - there was no significant impact to unicast traffic. PIM-SM was enabled on the L3 VLAN interface - creating the local IGMP querier - the IPTV headend was connected to a separate VLAN - with users in a "User" VLAN. We monitored the PIM state during a problem period - no change was seen - Inbound & outbound interfaces remained unchanged. It was clear this issue was at a IGMP snooping level. Debugging for IGMP snooping showed no root cause - and IGMP state appeared to remain stable during the issue. To cut a long story very short, the issue turned out to be related to Spanning Tree. A command making user interfaces spanning tree "edge" ports by default had somehow been removed. This resulted in all ports participating in Spanning tree, and all interfaces triggering Spanning Tree Topology Changes (TCN's) every time the interface went up and down. These TCN's resulted in Spanning Tree flushing the MAC table & flooding all traffic - with IGMP using the MAC address table for forwarding decisions, this caused IGMP to flood traffic. So - if IGMP is configured correctly & you are getting occasional multicast floods, check whether they coincide with Spanning Tree changes! A closer look at our Wireshark captures showed some unicast flooding at the start - but it was dwarfed by the Multicast flooding - simply due to the traffic levels from the local headend. As expected, the Spanning Tree TCN was there just before the start of the issue....... isn't hind-sight wonderful! Just thought I'd share as looking for a multicast issue when it was an underlying Spanning Tree issue caused a lot of pain!
... View more