PIX515 CPU Utilization..

Unanswered Question
Mar 8th, 2007

Just hooked this up today and with Vibhor's help I have the DMZ working with nothing but a test server in it replying to ping. But I noticed that the firewall slowed down after about an hour when I was viewing the configs and whatnot and I did a sh cpu usage and got this back:

LINTHpix515# sh cpu usage

CPU utilization for 5 seconds = 96%; 1 minute: 96%; 5 minutes: 97%

Very high, what do I need to look for?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
abinjola Thu, 03/08/2007 - 12:38

please verify the amount of traffic and the connections :-

1)sh conn count

2)sh xlate count

3)sh traffic

4)sh proc mem

Which code are you running ?

Is there any URL server configured ?

for preliminary troubleshooting..the above outputs should be enough

thebrom Thu, 03/08/2007 - 12:47

LINTHpix515# sh conn count

160 in use, 384 most used

LINTHpix515# sh traff count

outside:

received (in 23920.770 secs):

2038832 packets 1452267727 bytes

85 pkts/sec 60172 bytes/sec

transmitted (in 23920.770 secs):

1725902 packets 667369321 bytes

72 pkts/sec 27001 bytes/sec

inside:

received (in 23920.770 secs):

52556502 packets 1560072202 bytes

2017 pkts/sec 65038 bytes/sec

transmitted (in 23920.770 secs):

154403316 packets 2249075846 bytes

6095 pkts/sec 94021 bytes/sec

dmz:

received (in 23920.820 secs):

138299 packets 12667907 bytes

5 pkts/sec 170 bytes/sec

transmitted (in 23920.820 secs):

14366 packets 1471404 bytes

0 pkts/sec 61 bytes/sec

LINTHpix515# sh xlate count

228 in use, 439 most used

I have http server disabled.

thebrom Thu, 03/08/2007 - 12:49

LINTHpix515(config)# sh proc

PC SP STATE Runtime SBASE Stack Process

Hsi 001f02c9 0096f5bc 0056ed50 330 0096e634 3488/4096 arp_timer

Lsi 001f5a95 00a127b4 0056ed50 150 00a1183c 3696/4096 FragDBGC

Lwe 0011a13f 00a1e95c 005724b8 0 00a1daf4 3688/4096 dbgtrace

Lwe 003fb2fd 00a20aec 00567688 13471910 00a1eba4 6152/8192 Logger

Hsi 003ff455 00a23be4 0056ed50 280 00a21c6c 7760/8192 tcp_fast

Hsi 003ff2f5 00a25c94 0056ed50 170 00a23d1c 7864/8192 tcp_slow

Lsi 00314885 00b5c414 0056ed50 10 00b5b48c 3816/4096 xlate clean

Lsi 00314793 00b5d4b4 0056ed50 0 00b5c53c 3548/4096 uxlate clean

Mwe 0030be5f 00cfd8b4 0056ed50 340 00cfb91c 7664/8192 tcp_intercept_timer_process

Lsi 00452ee5 00daa28c 0056ed50 20 00da9304 3736/4096 route_process

Hsi 002fb6fc 00dab31c 0056ed50 650 00daa3b4 2472/4096 PIX Garbage Collector

Hwe 0021e529 00db584c 0056ed50 120 00db18e4 13040/16384 isakmp_time_keeper

Lsi 002f929c 00dcf5e4 0056ed50 0 00dce65c 3944/4096 perfmon

Mwe 00214d39 00df9a14 0056ed50 270 00df7a9c 5264/8192 IPsec timer handler

Mwe 0026d0dd 00e288b4 0056ed50 130 00e2494c 15432/16384 IP Background

Lwe 0030cad6 00edb204 00585368 0 00eda38c 3704/4096 pix/trace

Lwe 0030cd0e 00edc2b4 00585a98 0 00edb43c 3704/4096 pix/tconsole

Hwe 0011fa67 00ee818c 0051bc10 100 00ee47a4 14508/16384 ci/console

Csi 003048fb 00ee97ac 0056ed50 470 00ee8854 3296/4096 update_cpu_usage

Hwe 002ef791 00f9a554 0054e100 0 00f966cc 15884/16384 uauth_in

Hwe 003fdf05 00f9c654 008e6a80 0 00f9a77c 7896/8192 uauth_thread

Hwe 0041553a 00f9d7a4 00567c88 0 00f9c82c 3928/4096 udp_timer

Hsi 001e7d4e 00f9f464 0056ed50 50 00f9e4ec 3768/4096 557mcfix

Crd 001e7d03 00fa0524 0056f1c8 7486200 00f9f59c 3580/4096 557poll

Lsi 001e7dbd 00fa15c4 0056ed50 130 00fa064c 3688/4096 557timer

Cwe 001e99a9 00fb769c 007ce058 79930 00fb57a4 6012/8192 pix/intf0

Mwe 004152aa 00fb87ac 00930c70 0 00fb7874 3896/4096 riprx/0

Msi 003ba8a1 00fb98bc 0056ed50 0 00fb8944 3888/4096 riptx/0

Cwe 001e99a9 00fbfac4 00756ae0 1219800 00fbdbcc 6000/8192 pix/intf1

Mwe 004152aa 00fc0bd4 00930c28 0 00fbfc9c 3896/4096 riprx/1

Msi 003ba8a1 00fc1ce4 0056ed50 0 00fc0d6c 3888/4096 riptx/1

Cwe 001e99a9 00fc7eec 008455d0 2650 00fc5ff4 6192/8192 pix/intf2

Mwe 004152aa 00fc8ffc 00930be0 0 00fc80c4 3896/4096 riprx/2

Msi 003ba8a1 00fca10c 0056ed50 0 00fc9194 3888/4096 riptx/2

Hwe 003fe199 01083224 008bd208 0 01082b7c 1308/2048 listen/http1

Hwe 004152aa 01083dd4 00930b50 0 0108342c 2356/4096 snmp

Hwe 004152aa 01084a0c 00930b98 0 010846c4 840/1024 snmp_ex

Hwe 003e4e45 0108fb14 0108ffc4 4810 0108dcec 5796/8192 isakmp_receiver

Hwe 003fe199 01090a34 008bd6e0 0 010903ec 1196/2048 listen/telnet_1

Hwe 003fe199 0109133c 008bd3f8 0 01090cf4 1196/2048 listen/ssh_0

Hwe 003fe199 01091c44 008bd4f0 0 010915fc 1196/2048 listen/ssh_1

Mwe 0038707e 01094c3c 0056ed50 0 01092cc4 7960/8192 Crypto CA

Mwe 003f7ded 0112a9dc 0056ed50 0 01128a64 7872/8192 ssh/timer

M* 003f101c 0009ff2c 0056ed88 460 011bb134 11944/16384 ssh

LINTHpix515(config)# sh ver

Cisco PIX Firewall Version 6.3(5)

Cisco PIX Device Manager Version 3.0(4)

Compiled on Thu 04-Aug-05 21:40 by morlee

LINTHpix515 up 6 hours 42 mins

Hardware: PIX-515E, 64 MB RAM, CPU Pentium II 433 MHz

Flash E28F128J3 @ 0x300, 16MB

BIOS Flash AM29F400B @ 0xfffd8000, 32KB

Licensed Features:

Failover: Disabled

VPN-DES: Enabled

VPN-3DES-AES: Enabled

Maximum Physical Interfaces: 3

Maximum Interfaces: 5

abinjola Thu, 03/08/2007 - 15:18

do you have a URL server configured, by URL I mean any URL filtering server Integrated with the firewall ?

Also how many VPN Tunnels are currently active at this time ?

thebrom Thu, 03/08/2007 - 15:27

No I don't have a URL server like websense or anything, no.

to be honest I simply turned off logging and it went down to close to 0%.

I have never had an issue with logging in the past to a syslog server. I have 5 tunnels but very few of them are hevily used, and a lot of them are DES, not 3DES.

vitripat Thu, 03/08/2007 - 15:37

Thanks for the updates. I believe that your syslog server was not available in that case or service might not be running. When that happens, PIX sends the log messages to the server and forgets as this is UDP, however as the service is not running on the server, it sends back a ICMP unreachable message to PIX. This would also clarify as to why you had too much traffic on the inside interface of PIX.

Hope this explains the reasons.

Regards,

Vibhor.

thebrom Thu, 03/08/2007 - 18:36

you're exactly right. I was shutting off the syslog on my own machine and then I would see a lot of unreachables later on. I will turn my logging back on and see if it makes a big diff with the syslog actually running on my machine.

vitripat Thu, 03/08/2007 - 15:33

Please check the "sh traffic count" output-

outside:

received (in 23920.770 secs):

85 pkts/sec 60172 bytes/sec

transmitted (in 23920.770 secs):

72 pkts/sec 27001 bytes/sec

nside:

received (in 23920.770 secs):

2017 pkts/sec 65038 bytes/sec

transmitted (in 23920.770 secs):

6095 pkts/sec 94021 bytes/sec

dmz:

received (in 23920.820 secs):

5 pkts/sec 170 bytes/sec

transmitted (in 23920.820 secs):

0 pkts/sec 61 bytes/sec

The "inside" interface seems to be recieving far too much traffic that is supposed to be transmitted through the firewall. Can you check the output of "show interface" and check if there are any overruns on the inside interface of PIX? No. of connections and xlates on PIX look very normal. Can you also collect syslogs at the time you have high CPU usage?

Regards,

Vibhor.

abinjola Thu, 03/08/2007 - 18:26

Syslogging is never recommended to run at debug level, moreover when your traffic is huge

Actions

This Discussion