We are investigating a problem with unreasonably high CPU utilization, with one of our FWSM modules in a 6509-E. This is a newly implemented module with practically zero traffic passing through it but still, the CPU is at 20-22%. Here's some information:
<FWSM>/actNoFailover# sh ver
FWSM Firewall Version 3.1(10) Device Manager Version 6.2(1)F
<FWSM>/actNoFailover# show pc conn 0 in use, 0 most used
<FWSM>/actNoFailover# sh resource usage Resource Current Peak Limit Denied Context Telnet 1 2 5 0 System ASDM 1 1 5 0 System Conns 11 35 unlimited 0 System Xlates 12 124 unlimited 0 System Hosts 12 124 unlimited 0 System
fw-mgmtdc-kln-01/actNoFailover# sh processes cpu-hog
MAXHOG NUMHOG LASTHOG Process -------------- --------------- --------------- ---------
<FWSM># sh cpu usage CPU utilization for 5 seconds = 18%; 1 minute: 18%; 5 minutes: 18%
Please let me know if you require any additional information so that i will provide them. Any help as to why we are getting such high CPU readings, will be greatly appreciated.
Re: FWSM 3.1(10): Unreasonably high CPU utilization
OK, so it seems the 3 top processes are Dispatch Unit, snp_timer_thread and OSPF. As jajohnst mentioned with OSPD it is normal and expected that the CPU utilizationincrease to around 20% continuously, with no traffic through the FWSM. Eventhough the CPU is at 20% due to the OSPF process, that process willyield the CPU usage if it is required for other, higher priority tasks(such as packet processing on the control-point).
The Dispatch Unit is packet processing so it is normal to take cpu.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...