cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1010
Views
0
Helpful
7
Replies

Pix 515E Pass through speed issue

tharden
Level 1
Level 1

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

7 Replies 7

bernhardb
Level 1
Level 1

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

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.

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

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.

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

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.

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.

Getting Started

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: