03-13-2006 05:38 AM - edited 02-21-2020 12:46 AM
We have a Pix 515E that was installed last November and in just the last 5-7 weeks we have been noting a massive speed decrease on through put. After much trouble shooting it turns out to be the Pix causing the problems.
Example if issue: network looks like following
Edge route-----Pix515E-----core router/switch-----ftp servers
If I connect to either the second interface of the Edge router or the segment between the Edge and PIX and I ftp to one of our servers I will be lucky to get 50-100Kbs.
If I connect to the segment between the Pix and core router/switch I will get 2-5Mbs.
This slowdown is starting to cause massive mail issues as well as issues with anything that needs the bandwidth .or everything!
Pix is running IOS 7.
Pix performs the following
-VPN tunnel over internet to Pix at remote office
-VPN access for employees to local and remote office
-Normal firewall duties
-One to one routable IP
-One to one Nat
-One to many Nat
Does anyone have any ideas what could cause this type of problem? I will post a copy of our running config if you need to see it (it will take me a few to change the names to protect the innocent).
Thanks
T
03-13-2006 06:24 AM
Hi!
Are you experiencing much UDP traffic?
What is your average packet size?
Did you always use OS 7?
Because 6.3 is much speedier...
Also small Packets and UDP traffic is slowing PIX firewalls extremly...
What inspections do you use?
greetz
03-13-2006 07:49 AM
We upgraded to OS 7 about 2-3 weeks ago so that our VPN clients could access the server over the Point-to-Point VPN tunnel with our other office. But the problem started before that, but has gotten a little worse after the upgrade(it seems).
According to the Pix you are doing mostly TCP and HTTP connections. (according to show perfmon and show counters).
How do I see the avg packet size and what inspections we use?
Thanks for your time.
03-13-2006 08:00 AM
I did just note something as I was crawling through the show tech that I didn't note before. Note the Output errors on both sides of my Pix. That is strange.
Interface Ethernet0 "outside", is up, line protocol is up
Hardware is i82559, BW 100 Mbps
Auto-Duplex(Half-duplex), Auto-Speed(100 Mbps)
MAC address 0014.69e9.****, MTU 1500
IP address **.**.**.**, subnet mask 255.255.255.192
15059141 packets input, 4473754850 bytes, 0 no buffer
Received 20389 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 L2 decode drops
14353049 packets output, 4086746653 bytes, 0 underruns
0 output errors, 8496 collisions, 0 interface resets
0 babbles, 5384 late collisions, 10113 deferred
30 lost carrier, 0 no carrier
input queue (curr/max blocks): hardware (128/128) software (1/43)
output queue (curr/max blocks): hardware (0/25) software (0/1)
Traffic Statistics for "outside":
15051391 packets input, 4239880295 bytes
14359265 packets output, 3832733100 bytes
1529559 packets dropped
Control Point Interface States:
Interface number is 1
Interface config status is active
Interface state is active
Interface Ethernet1 "inside", is up, line protocol is up
Hardware is i82559, BW 100 Mbps
Auto-Duplex(Half-duplex), Auto-Speed(100 Mbps)
MAC address 0014.69e9.****, MTU 1500
IP address **.**.**.**, subnet mask 255.255.255.192
14313350 packets input, 4053334962 bytes, 0 no buffer
Received 4265 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 L2 decode drops
13581851 packets output, 4240345689 bytes, 0 underruns
0 output errors, 40639 collisions, 0 interface resets
0 babbles, 21813 late collisions, 32697 deferred
0 lost carrier, 0 no carrier
input queue (curr/max blocks): hardware (128/128) software (0/25)
output queue (curr/max blocks): hardware (0/60) software (0/1)
Traffic Statistics for "inside":
333389347 packets input, 67168561275 bytes
293759430 packets output, 89943013578 bytes
10909393 packets dropped
Control Point Interface States:
Interface number is 2
Interface config status is active
Interface state is active
03-13-2006 03:06 PM
It auto negotiate 100M half duplex, hard-code the pix and the switches (or routers) to 100 full and see if your problem goes away.
03-13-2006 06:05 PM
Yes, as < bjames > told it allready. If you change from half duplex to full duplex then all the collisions will disappear.
As an example, say your switch is hard-coded for 100 Mbps and full-dupex, and you connect your PIX into it, with the PIX's interface set to autonegotiation. The PIX sends out FLPs, but the switch doesn't respond because it is hard-coded for speed/duplex and doesn't participate in autonegotiation. Receiving no response from the switch, the PIX goes into Parallel Detection mode and senses the length of the pulses in the frames the switch is sending out. Thus the PIX can sense that the switch is set to 100 Mbps, so it sets its interface speed accordingly. However, because the switch will not exchange FLPs, the PIX has no way of knowing if the switch is capable of running full-duplex, so the PIX sets its interface duplex to half-duplex, per the standard. But the switch is hard-coded to 100 Mbps and full-duplex, and the PIX has just autonegotiated to 100 Mbps and half-duplex (as it should). The result is a duplex mismatch that will cause severe performance problems.
The only thing that I find really strange is that you have late collisions. This is usually a cabling problem, the cable length us longer than 100 meters an cause that late collisions.
Check your duplex settings.
See also Monitoring PIX Performance:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008009491c.shtml
sincerely
Patrick
03-15-2006 05:37 AM
After correcting the speed and duplex issue, which I should have looked at before, I did some testing.
I'm still not getting that good of a pass through on my pix. If I connect to the segment on the outside of the outside interface and FTP a file I am not getting 800-900kbs which is a big improvement.
When I connect to the segment just inside the inside interface I can FTP same file at speeds of 2.2-2.5mbs.
For something that is connected at 100b-Full on both sides I would expect to see quite a bit faster speed through the PIX.
03-22-2006 07:35 PM
Can you post or upload your config? Like the other guys said...hardcoding 100/full on the pix interface will definitely fix this. What you also need to do is make sure you hard code it all the way through.. Hard code it on the edge router, the pix, the switch, and then the ftp server. It might seem tedious but auto-negotiation has been an evil thing to all of us. I hard code everything. There are definite improvements when this is done.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: