I hope this is the right place for multicast and IGMP questions...
The company I am working for provides IPTV services to hotels. The IPTVs are using multicast. The multicast traffic sources are located on a 3750G switch. The switch is also the root for the spanning-tree of the vlan.
There is just one vlan for the multicast so there is only IGMP snooping but no multicast routing (PIM) enabled anywhere. This switch is configured to be the querier for the vlan and no other switches are configured to be the queriers.
Then this switch is connected to two distribution layer switches WS-C4900M (spanning tree correctly blocked one link for this vlan) which in turn connect to other access switches. The multicast traffic recipients (Set Top Boxes or STBs) are located on the access switches (2960).
All other switches except of the 3750 are not managed by us and they are having cabling issues all around. Then the spanning-tree keeps changing (I think). For example on this 3750 switch, when I do "debug ip igmp snooping management" I got these from time to time:
*Mar 17 22:23:38.928: IGMPSN: mgt: Received topology change on vlan 2138
*Mar 17 22:23:38.928: IGMPSN: mgt: Topo-change updates all GCEs with flood portset for in Vlan 2138
*Mar 17 22:23:38.928: IGMPSN: mgt: Updating all GCEs with flood portset for in Vlan 2138
I tried to paste them in the "cisco output interpreter" but it can't find anything. I tried to search GCE and found nothing as well. What is GCE?
I have a STB on port g1/0/15 and when I do "show int g1/0/15 summary" and I see a lot drops on the interface and it's because of the traffic volume is higher than the bandwidth (the link is actually operating on 100Mbps). I did port mirroring and they are all multicast traffic destinated to all multicast channels... However the STB is not joining any of the multicast group at all.
your findings are interesting: they show that IGMP snooping activity is influenced by underlying Spanning-tree activity.
The three lines of debug ip igmp management should mean:
IGMP detects a change in STP topology, this potentially impact all multicast groups to port associations because STP sets low CAM timers and there is a potential for some mac addresses to be "moved" to another link/port if STP state changes on ports to other switches.
IGMP management reaction is to flood all groups out all ports waiting for STP to stabilize.
GCE should be a group entry, it is telling that each multicast group entry is flagged with flood.
Use ip igmp snooping tcn flood query count global configuration command to control the time that multicast traffic is flooded after a TCN event. If you set the TCN flood query count to 1 by using the ip igmp snooping tcn flood query count command, the flooding stops after receiving 1 general query. If you set the count to 7, the flooding of multicast traffic due to the TCN event lasts until 7 general queries are received. Groups are relearned based on the general queries received during the TCN event.
so you can minimize the duration of the flooding behaviour with above command
There is also an interface based command to disable flooding of multicast groups of per port basis
Use the ip igmp snooping tcn flood interface configurationcommand on the switch stack or on a standalone switch to specify multicast flooding as the Internet Group Management Protocol (IGMP) snooping spanning-tree Topology Change Notification (TCN) behavior. Use the no form of this command to disable the multicast flooding.
ip igmp snooping tcnflood
no ip igmp snooping tcnflood
This example shows how to disable the multicast flooding on an interface:
Switch(config)# interface gigabitethernet1/0/2
Switch(config-if)# noip igmp snooping tcn flood
Given that the other switches are not under your control
>> All other switches except of the 3750 are not managed by us and they are having cabling issues all around
I guess the other party is probably a customer building.
To be noted that the effect may be more heavy on your switch that on access layer switch.
Usually this IPTV setup uses to force single IGMP membership per port.
Try to see if the command
noip igmp snooping tcn flood
can be of help in your case by giving it on all interfaces of interest. you can test the command on gi1/0/15
Thank you very much for your quick reply! Actaully I have already put "no ip igmp snooping tcn flood" under the G1/0/5 interface but still no help (sorry I forgot to mention it in my earlier post)... I never configured the "ip igmp snooping tcn flood query count #" command. So I was thinking to set the count to 0 so there won't be flood at all however the minimum it can take is 1!! So anyway I set it to one however the G1/0/5 still has tremendous traffic...
Do I need to put "no ip igmp snooping tcn flood" under the source interfaces as well? I mean the interfaces that the multicast traffic sources are connected on? Will that help the situation? Thank you!
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...