cisco cpu % monitoring

Thanks Walter, i guess you can't have cpu warnings displayed on the cisco router log!? I was thinking of setting up mrtg if this was not possible.

Is there any tips that I can use to free up more cpu, such as ip route-cache on 1600's and 2600's handling high traffic in/out?

In article , yo wrote: :is there a way to log cpu usuage on a 1600/2600 and mem/enviroment :conditions to the buffered log. I think i have a cisco thats droping :the wan connection because of high cpu usage.

:Thanks Walter, i guess you can't have cpu warnings displayed on the :cisco router log!? I was thinking of setting up mrtg if this was not :possible.

Sorry, I don't know IOS well enough to know the answer to that.

:Is there any tips that I can use to free up more cpu, such as ip :route-cache on 1600's and 2600's handling high traffic in/out?

I do not work with IOS much, so this is all going by memory of what I've read online:

- the 1600 and 2600 do not, if I recall correctly, have real distributed processing of packets, so it is best not to do per-packet load balancing with them

- In the last few major releases, CEF is the most efficient, but before that on the low end devices, process switching was more efficient than CEF.

- packet inspection takes real CPU time on the 1600/2600, so use minimal 'inspect' and IDS features.

- on the low end devices, there is a noticable penalty in ACLs for the first entry that extracts layer 4 information (port numbers); this penalty is not paid in the ACL processing until that point, and is not paid again for that packet for any other later entries that need the information. Thus if you are CPU bound, move the port checks further down or eliminate them

- if you have ACLs that block all traffic to certain destinations, then in many Cisco devices, it is more efficient to remove that ACL entry and route that destination to NULL0. I do not know if this holds for policy based routing

- nat translation tables take time and memory

- syslog takes resources. If you are logging for accounting purposes, netflow is more efficient

- serial console takes a lot of resources. If you need to manage the device, telnet/ssh is a lot more efficient; and set up the logging levels so that only the really important things get logged to the serial port. If you are CPU bound, then sending debug traffic to the serial console is really hard on the device.

- if you don't have a VPN accelerator, then ssh to the device is harder on the device than telnet

- if you don't have a VPN accelarator, any kind of VPN tunnel (e.g., IPSec, PPTP, GRE) is a drain on the device CPU.