cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1466
Views
5
Helpful
7
Replies

WS-4948 K2PortMan Review high

mariov652
Level 1
Level 1

Hello all,

Our new Catalyst 4948 shows high CPU useage.

Despite reading many articles and going gover CISCO's document regarding high CPU on the 4948's, we have not been able to find a solution.

We think we've narrowed down the problem to high utilization from the "K2PortMan Review" process, but we are not sure on how to proceed to resolve it.

The process is using 4.27 % CPU where it's target is 2%.

The "K2PortMan Review" process is responsible for "..managing various port related programming functions".

Any advice or assistance to narrow down this problem would be appreciated.

IOS version: cat4000-i5k91s-mz.122-25.EWA14.bin

Regards,

P.S. - We've jusdt noticed too that the "K2PacketBufMonitor-P" process utilizes 3% CPU where the target is 1%.

These 2 seem to be related and again, any advice would be appreciated.

1 Accepted Solution

Accepted Solutions

Those multicast packets are link-local multicast.

224.0.0.10 <- EIGRP

224.0.0.13 <- PIM

These packets need to be processed by the switch as they are control packets and the CPU has to inspect them.

Other multicast packets should be processed in hardware.

View solution in original post

7 Replies 7

mihanlin
Level 1
Level 1

Hello,

These values you mention for K2Portman review and K2PacketBufMonitor are very small amounts. Together, they only account for 7.27% of total CPU.

Firstly, what is your overall CPU utilisation from "show proc cpu"

Second, what is the highest process by CPU when you issue the command "show platform health"

Thanks,

Michael

Morning,

First of all, thank you for attempting to help.

I agree. The overall CPU is not extremely high, but it is higher than other switches I've worked with. In particular, however these two processes consistantly show their "Actual Values" to be greater than their "Target Values" - A sign of a problem from the CISCO document in my original mail. (Link is here: http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a00804cef15.shtml)

These two processes are also the two top CPU processes from the "sh platform health" command. Output this morning is:

Target Actual

K2PortMan Review 3.00 6.01

K2PacketBufMonitor-P 3.00 3.25

sh proc cpu sorted shows:

CPU utilization for five seconds: 10%/0%; one minute: 11%; five minutes: 11%

uSecs 5Sec 1Min 5Min TTY Process

1982 6.87% 7.83% 8.32% 0 Cat4k Mgmt LoPri

178 2.87% 2.84% 2.87% 0 Cat4k Mgmt HiPri

I've attached a file with the output of the relevant commands for easier reading.

Hi,

Has anyone else got any any input/advice they may be able to share regarding this problem?

Thanks,

Mario

You should check out CSCsh86127 - K2PacketBufMonitor-P consistently blowing CPU target

Looks like it's only integrated in 12.2(37)SG or later IOS.

As mentioned however, this is not actually causing a problem with the switch, just the way the target CPU is calculated.

Thank you,

We have upgraded to 12.2(46) and although the K2PacketBufMonitor-P seems to be in order, the "K2PortMan Review" still shows these figues:

Target - 3.00

Actual - 3.75

I've also checked with the "debug platform packet all receive buffer" enabled and run a "sh platform cpu packet buffered" command to check what data is actually been sent to the CPU.

It looks like much of the multicast forwarding is been done via CPU rather than hardware.

I attached a file showing the output.

The network is very simple:

1 router supplying multicast feed via a port on the switch. 2 systems that join various multicast groups with very limited TCP routed from the startions via the router.

IGMP is working correctly etc. My main concern is that is looks like the traffic is sent by CPU rather than hardware, where it would be quicker.

Any additional comments or assistance would be greatly appreciated.

Those multicast packets are link-local multicast.

224.0.0.10 <- EIGRP

224.0.0.13 <- PIM

These packets need to be processed by the switch as they are control packets and the CPU has to inspect them.

Other multicast packets should be processed in hardware.

Ok, so from what you are saying I am fussing over nothing and things are behaving as they should be.

Thank you for taking the time to answer my query. You've been most helpful.

Kind Regards,

Mario

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: