High CPU - IP Input Process

Unanswered Question
Sep 26th, 2009
User Badges:

Hi,


I'm testing a multicqst application (server and client) and am experiencing very high CPU load on my 4948 due to the IP Input Process.


I've read document ID 41160 related to this but don't have a solution yet.


It's a very basic test scenario, with server and client in the same VLAN.


With no querier in the VLAN, multicast is sent to all VLAN ports and CPU rtemains low. As soon as I enable the the VLAN's interface, the CPU goes to 80% +.


This occurs even with 2Mbps multicast which should not tax the switch.


My VLAN interface config is below. Does anyone have any ideas for me?


interface Vlan2

description Test multicast VLAN

ip address 192.168.20.2 255.255.255.0 secondary

ip address 192.168.20.1 255.255.255.0

no ip redirects

ip pim dr-priority 20

ip pim sparse-mode

ip igmp access-group ABC



Thanks,

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Sat, 09/26/2009 - 04:18
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Mario,

you are using PIM sparse-mode, have you configured an RP for the multicast groups in your lab?


try also to use

ip pim dense-mode instead of ip pim sparse-mode.


Hope to help

Giuseppe


mariov652 Sat, 09/26/2009 - 10:05
User Badges:

Hi Giuseppem


Yes, I have configured an rp with access list 'ABC' as below:


'ip pim rp address 192.168.20.26 ABC'



'ip access-list standard EbsA

permit 224.24.24.0 0.0.0.255

deny any'


It is pointing to my 'muticast source' (I am testing using Nortel's Multicast Hammer Application).



Unfortunately I need to test and get working in sparse mode because the production system I will use uses pim sparse-mode.



The CPU seems to increase only after a few seconds the multicast is enabled - Makes me think that maybe some buffer has filled, but I'm not sure what to check for this.


The debug log shows some errors for routing to the rp, but I havn't understood yet what they mean.

Lucien Avramov Sat, 09/26/2009 - 10:26
User Badges:
  • Red, 2250 points or more

Does the cpu stay high for a long period? It's ok to have a high cpu for a short time. Multicast is resource consuming when you enable it.

mariov652 Sat, 09/26/2009 - 23:15
User Badges:

Hi,


Yes, the CPU stays high, even getting to 100% when sending 2Mbps.


If the VLAN interface is not enabled, the multicast is broadcast to all ports in the VLAN, and the CPU is not affected at all.

Only once I enable the VLAN interface does the CPU increase.


The config above shows the setting I have for the VLAN interface.

Giuseppe Larosa Sat, 09/26/2009 - 10:52
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Mario,

this is fine.


And you are sure you haven't a


ip igmp join-group G

under any L3 interface on the device?


because it causes packets to be process switched= sent to main cpu, it makes the device a real receiver of the stream.


Hope to help

Giuseppe


mariov652 Sat, 09/26/2009 - 23:19
User Badges:

Hi Giuseppe,


I definitely don't have a ip igmp join-group anywhere on the device.


I've also disabled all L3 interfaces except for the vlan I am working in.


I'm using IOS 12.2.50. I haven't seen any CPU issues with this IOS, but I may try an earlier version later tonight to see if I get the same result.

mariov652 Mon, 09/28/2009 - 02:36
User Badges:

I've done some additional testing. It made no difference when trying a different IOS.


I think the issue is related to a routing issue.


The Hgh CPU occurs only if I enable the vlan interface (i've used vlan 2) and then only if I set the rp to the multicast test source which is in that vlan.


With no rp or vlan interface enabled, packets are broadcasted to all ports in the vlan with no excessive CPU.


I don't understand why I get 'routing errors' when the multicast source is a station in the same vlan.


Even if I have no multicast and I ping the station from the switch, the sending packet is fine, but the reply reports as 'routing error' when the source of the reply is the test station.


I've attached a summary of the errors which may help someone understand what configuration is wrong.


In the attached, 192.168.20.1 is my switch IP, and 192.168.20.26 is my test source station.



Actions

This Discussion