High latency and packet drops observed between the physical interfaces of ASA 5510 Ver 8.4(6)5

[canand001]

Hi Folks,

              I am observing packet drops between the interfaces of ASA firewall. In other terms, I have PC-A on Vlan-48 associated with the physical interface Ethernet 0/0.48 and PC-B on Vlan 52 associated with the physical interface Ethernet 0/1.52. When I try to ping between the PC's, I get latencies upto 50ms with packet drops. But when I ping a different Vlan configured under the same physical interface, the response is fine without drops. Below are the interface stats of both the interfaces. Can anyone show some light on the actual problem that's causing this? Would greatly appreciate it.

Interface Ethernet0/0 "", is up, line protocol is up
  Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
        Auto-Duplex(Full-duplex), Auto-Speed(1000 Mbps)
        Input flow control is unsupported, output flow control is off
        Available but not configured via nameif
        MAC address 44d3.ca0f.0e9c, MTU not set
        IP address unassigned
        978429 packets input, 484401147 bytes, 0 no buffer
        Received 79970 broadcasts, 0 runts, 0 giants
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 pause input, 0 resume input
        52740 L2 decode drops
        1160863 packets output, 777595252 bytes, 0 underruns
        0 pause output, 0 resume output
        0 output errors, 0 collisions, 0 interface resets
        0 late collisions, 0 deferred
        0 input reset drops, 0 output reset drops, 0 tx hangs
        input queue (blocks free curr/low): hardware (255/230)
        output queue (blocks free curr/low): hardware (255/65)

Interface Ethernet0/1 "inside", is up, line protocol is up
  Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
        Auto-Duplex(Full-duplex), Auto-Speed(1000 Mbps)
        Input flow control is unsupported, output flow control is off
        MAC address 44d3.ca0f.0e9d, MTU 1500
        IP address unassigned
        1456106 packets input, 506247554 bytes, 0 no buffer
        Received 84411 broadcasts, 0 runts, 0 giants
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 pause input, 0 resume input
        87040 L2 decode drops
        1416324 packets output, 1322034376 bytes, 0 underruns
        0 pause output, 0 resume output
        0 output errors, 0 collisions, 0 interface resets
        0 late collisions, 0 deferred
        0 input reset drops, 0 output reset drops, 0 tx hangs
        input queue (blocks free curr/low): hardware (255/230)
        output queue (blocks free curr/low): hardware (255/0)
  Traffic Statistics for "inside":
        11594 packets input, 731663 bytes
        3 packets output, 84 bytes
        11594 packets dropped
           

Cyril

[Vibhor Amrodia]

Hi,

Okay , so you checked the latency test on one end of the Sub Interfaces. Can you also check on the other end and see if that also works fine ?

After that , i would recommend taking the captures on the ASA device on the Ingress and Egress and see how much time difference is there when the packet enters and leaves the ASA device.

Packet Captures:-

https://supportforums.cisco.com/document/6971/packet-capture-asapix-fwsm

Thanks and Regards,

Vibhor Amrodia

[canand001]

Hi Vibhor,

Sorry for the delay in revert. Yes, I did check the other end as well. They also seem to be fine without any issues.

As suggested, I had taken captures between the Src & Dstn in the Ingress and the egress interfaces of the firewall respectively. Yet..I don't observe much of a difference/delay in the query and reply timings.But I still can find drops to the destination hosts while performing a continuous ping. Logs attached for your kind reference.

I am afraid this could be due to the high CPU utilization (90% Avg.). I doubt this could possibly be a bug as I don't find the reason behind the high utilization. Traffic status,connection counts and service policy for TCP inspection everything has been thoroughly checked....yet couldn't find the cause for this...

Any help on this will always be welcomed....

Thanks 

Cyril