Have you checked you intrface for ERRORS and have you verified that your Switch and ASA/PIX have the same Duplex and Link Speed settings.
Do a < show interface > to see if you have CRC, Short packages ....
Speed and Duplex Settings
The PIX is preconfigured to autodetect the speed and duplex settings on an interface. However, there are several things that can cause the autonegotiation process to fail, resulting in either speed or duplex mismatches (and performance issues). For mission-critical network infrastructure, it is Cisco's overall policy to manually hard-code the speed and duplex on each interface so there is no chance for error. These devices generally do not move around, so if you set them up properly to begin with, you should not have to change them.
On any network device, link speed can be sensed, whereas duplex must be negotiated. If two network devices are configured to autonegotiate speed/duplex, they will exchange a couple of frames (called Fast Link Pulses, or FLPs) that advertise their speed and duplex capabilities. These pulses look like regular 10 Mbps frames to an unaware link partner. But to link partners that can decode the pulses, the FLPs contain all the speed and duplex settings that the link partner can provide. The receiving station then acknowledges the frames, and the devices mutually agree on the highest speed and duplex settings that each can achieve. If one side does not support autonegotiation, the other side will not receive the FLPs and will go into Parallel Detection mode, sensing the speed of the partner by listening to the length of pulses and then setting speed accordingly. The problem arises with the duplex setting. Since duplex must be negotiated, the side that is set to autonegotiate has no way of determining the settings on the other side, so it defaults to half-duplex per the IEEE 802.3u standard.
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.
A duplex mismatch is most frequently revealed by increasing error counters on the interfaces in question. The most common errors are Frame, CRC, and Runts. If these values are incrementing on your interface, you either have a duplex mismatch or a cabling issue. Resolve this issue before you do anything else.
Example
interface ethernet0 "outside" is up, line protocol is up
Hardware is i82559 ethernet, address is 00d0.b78f.d579
IP address 192.168.1.1, subnet mask 255.255.255.0
MTU 1500 bytes, BW 100000 Kbit half duplex
7594 packets input, 2683406 bytes, 0 no buffer
Received 83 broadcasts, 153 runts, 0 giants
378 input errors, 106 CRC, 272 frame, 0 overrun, 0 ignored, 0 abort
2997 packets output, 817123 bytes, 0 underruns
0 output errors, 251 collisions, 0 interface resets
0 babbles, 150 late collisions, 110 deferred
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008009491c.shtml#speed
sincerely
Patrick
