cpu high on 6509

[athambi]

Hello ,

I am seeing 6509 cpu going randomly high .I enabled “ip flow egress” to see the packets coming into the box. When I look at the “show ip cache flow “command I see that the request to ip is getting processed in software only and the ip 10.10.10.12 is not active in network

Does to many of these request cause cpu to go high or not .how will be the packet be handled if IP is not active in network .

Cheers

Ajai

[Giuseppe Larosa]

Hello Ajai,

what type of supervisor, linecards are in the chassis?

if you like you may post a sh module.

According to documentation PFC3 netflow is automatically enabled when you configure netflow on the MSFC.

see

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/netflow.html#wp1078026

you can use

show mls netflow aggregation flowmask

to verify if MLS is enabled for netflow

However, this config guide shows only ip flow ingress and you have used

ip flow egress so you are using a later image

also config guide for 12.2(33)SXH shows only ip flow ingress

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/netflow.html#wp1144912

Netflow config guide lists egress netflow for 12.2SX but I wonder if it refers to different platforms

I would try to use ip flow ingress instead applied on interfaces receiving the flows you want to monitor

Hope to help

Giuseppe

[athambi]

I have enabled only ip flow egress.

My question was if the request comes in for an IP that is locally attached but not active as in host associated to that IP is not up ,will that be causing the look up to happen in software and cause the cpu to go high if the request are like 10 -15 in continous .As u can see from attached , mutiple source ip are requesting access to a single destination and tats getig punted in the software ..

Ajai

[Giuseppe Larosa]

Hello Ajai,

I see your point.

You see flows destinated to a currently unavailable host.

This means an ARP entry for that host doesn't exist.

Multilayer switches punt to main processor for ARP request but only one packet every N recognizing that is useless to ask the same ARP request multiple times.

So this shouldn't cause the problem you see because only a few of them are actually software processed with the other ones held in some buffers waiting for the ARP process to complete (and to fail in this case).

You can use sh proc cpu sorted 1min to find out what processes are using more cpu resources.

Anyway if you are sure that ip host is not connected do the following:

add

ip route host-address 255.255.255.255 null0 250

this should cause all these packets to be silently dropped in the waste bin without any process switching.

If you decide to do so you could see if the cpu usage lowers after adding the static route to null0.

Hope to help

Giuseppe

[athambi]

the task occupying cpu is ip

CPU utilization for five seconds: 47%/14%; one minute: 42%; five minutes: 43%

PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process

155 4565205722667043057 0 18.08% 18.62% 19.23% 0 IP Input

387 532416540 121313361 4388 5.15% 3.51% 3.53% 0 IGMP Input

389 25626320 71865017 356 2.21% 0.84% 0.84% 0 Mwheel Process

350 91433396 594403440 153 2.14% 0.86% 0.76% 0 Port manager per

392 154678512 415938244 371 2.14% 1.87% 2.02% 0 MLSM Process

391 68290768 47028775 1452 1.34% 0.77% 0.75% 0 PIM Process

148 15844576 49502071 320 0.71% 0.30% 0.27% 0 CDP Protocol

230 29284852 11136500 2629 0.39% 0.32% 0.32% 0 CEF: IPv4 proces

[Jake Gillen]

Hi,

I got this link from TAC a while back when I was running into the same type of thing:

http://cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml#utilities

I used this to take backplane sniffs, which helped us to see who was creating the problems.