Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

multicast and CPU overhead

Hello,

I use several Catalyst 3550 with equal IOS and configurations to route multicast. When i start multicsting i see that IP INPUT CPU overhead on one of switches raises to 90%. Other switches have normal CPU overhead with all networks subscribed to multicast group. I wondering what will couse this problem on switch.Any ideas ?

4 REPLIES
Silver

Re: multicast and CPU overhead

Post your configuration!

Do you have IGMP snooping enabled?

New Member

Re: multicast and CPU overhead

No i dont use snooping

Global Multicast configuration

no ip igmp snooping

ip multicast-routing

ip pim accept-register list multicast-accept-register

Extended IP access list multicast-accept-register

permit ip any 239.1.1.0 0.0.0.255

deny ip any any

Interface Multicast Configuration

ip pim dense-mode

ip multicast rate-limit in 1000

ip igmp join-group 239.1.1.1

ip igmp access-group IGMP

Standard IP access list IGMP

permit 239.1.1.0, wildcard bits 0.0.0.255 (19449 matches) check=35935

deny any (35935 matches)

However i see multicast routes that are no in 239.1.1.0 subnet. How to supress it

ip pim accept-register and ip igmp access-group seems to not working...

New Member

Re: multicast and CPU overhead

I use "ip multicast boundary" on clients interfaces for allowing only couple multicast group and the problem stops for now ...

New Member

Re: multicast and CPU overhead

The multicast server has a TTL value that is probably set to one. Raise this value to three or four as an experiment. The reason for this is a multicast with a TTL value of one must be process switched rather than switched in hardware, higher values aren't expiring so they are either propagated or discarded. The process switching means the CPU takes a hit on the 3500 because it is a layer three capable device. I have noticed this before with a much used desktop imaging product that is a good product but the TTL default is one, arrrrrgh!

Cheers,

Brian

234
Views
0
Helpful
4
Replies
CreatePlease to create content