03-08-2007 12:27 PM - edited 03-11-2019 02:43 AM
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?
03-08-2007 12:38 PM
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
03-08-2007 12:47 PM
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.
03-08-2007 12:49 PM
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
03-08-2007 03:18 PM
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 ?
03-08-2007 03:27 PM
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.
03-08-2007 03:37 PM
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.
03-08-2007 06:36 PM
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.
03-08-2007 03:33 PM
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.
03-08-2007 06:26 PM
Syslogging is never recommended to run at debug level, moreover when your traffic is huge
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide