6509 and 3524XL switches and multicast

[mike-t]

I recently upgraded my aging 10MB LAN to a full Cisco design with a Catalyst 6509 for the backbone with fiber GB interfaces to the 3524XL switches.

My problem is this, whenever we run a Multicast application (ghosting, etc) across the network, every device on every switch experiences performance problems, to the point of disconnection.

I have set the rising and falling range for multicast traffic to 1500 and 10 repsectively. At that point I noticed a slight improvement. Things were slow, very slow, but no one got disconnected from their applications.

Can anyone tell me how to setup my switches so that I don't have this huge multicast problem? (we have over 300 PC's at this location and ghosting is how we repair/upgrade the applications on them)

[wukunpeng]

By default, a LAN switch floods multicast traffic within the broadcast domain, and this can consume a lot of bandwidth if many multicast servers are sending streams to the segment.

Try to config PIM feature in your MSFC IOS,enable ICMP & CGMP in your cat6509 engine.

[mike-t]

OK thanks. I understand the CGMP, but had trouble configuring it initially. However what is PIM? and why would i bother using ICMP (ping??) on the 6500? what does that have to do with controlling broadcasts?

Thanks.

[milan.kulik]

Mike,

I spent a lot of time fixing Ghost multicast problem and this is my solution:

1) set a mutlicast storm control on the port the Ghost server (multicast source) is connected to the network. I'm using 2000 rising and 1500 falling thresholds. This decreases the absolute number of multicasts flooded to the network.

2) enable IGMP snooping on switches which are IGMP-snooping enable (Cat6500, 2950) and set CGMP enable on switches which are not (Cat4000). On Cat3500 and 2900 CGMP is enabled by default.

3) configure

ip pim sparse-mode

ip cgmp

on your router LAN port.

Don't use CGMP fast-leave if you're using HSRP in your network (address conflict).

The way this scenario works:

At the moment wokstation joins a multicast group it sends a IGMP join message. IGMP-enable switches detects it and they send multicast traffic to appropriate ports only then. IGMP-not-enabled switches receive this info through CGMP - a router "translating" from IGMP to CGMP is necessary.

There are some minor problems remaining (if the workstation joins several multicast groups rapidly it takes some time to detect it and aproximately 30 sec multicast storm apears, e.g.) but generally this scenario works.

The above description is very rough, for detailed info see:

http://www.cisco.com/warp/public/473/38.html

http://www.cisco.com/warp/public/473/22.html

http://service4.symantec.com/SUPPORT/ghost.nsf/docid/1999033015222425

A good news in the end: There is a new Ghost version available which should be much more flexible and user friendly regarding unicats/multicasts options.

Hope to help,

Milan

[mike-t]

thanks for the help. That seems to be the direction i am heading in. I have one question though. Is there a way to prevent certain ports from participating in the broadcasts? Like servers and routers?

[milan.kulik]

I don't understand what you exactly mean by "prevent certain ports from participating in the broadcasts". Do you mean to prevent routers or servers to receive or send broadcasts? If yes, that could be pretty dangerous - ARP requests are sent as broadcasts, e.g.

Anyway, you can configure port storm-control broadcast similar way to port storm-control multicast on your switch port. It would decraase the number of broadcast sent from the server or router to the network.

Regards,

Milan

[mike-t]

sorry, i meant to put Multicast broadcasts. Prevent them from receiving the broadcasts from the Ghost server. Anyway the docs you provided seemed to have done the trick.

Thanks

[dhirtz]

What are the guidlines/configuration to accomplish the transaltion from IGMP to CGMP on the router for Non-IGMP enable switches.