3750 switch flooding multicast traffic

Difan Zhao · ‎01-16-2010

Greetings!

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.

Any suggestion is appreciated! Thank you!

Giuseppe Larosa · ‎01-17-2010

Hello Zhaodifan,

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.

Your findings on port g1/0/15 confirms this.

this behaviour is regulated by a global command

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_46_se/command/reference/cli1.html#wp2238313

ip igmp snooping tcn flood query count

Usage Guidelines

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 configuration command 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 tcn flood

no ip igmp snooping tcn flood

This example shows how to disable the multicast flooding on an interface:

Switch(config)# interface gigabitethernet1/0/2

Switch(config-if)# no ip 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

no ip 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

Hope to help

Giuseppe

Difan Zhao · ‎01-17-2010

Hi Giuseppe,

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!

Giuseppe Larosa · ‎01-17-2010

Hello Zhaodifan,

I'm afraid you have already done all could be performed on your side.

You could try to add no ip igmp snooping tcn flood" under the source interfaces but I don't expect improvements.

It is strange however, because the command should be there for this objective.

What IOS image is running on the C3750?

You should report to your manager the root cause is STP instability on customer side so that an ufficial communication to this customer can be done.

But interfaces to customer's distribution switches are GE ports and show output drops or not?

I'm starting to think that there is no big effect on the customer side otherwise they would be complaining all the time (and may be it is what they are doing... )

Hope to help

Giuseppe