ASA 5545 Overrun on Interface Inside

[oyindamola15]

The only thing that changed the network was traffic.

Our traffic almost doubled and the inside interface had input error = overrun. The counter was increasing in real time.

Implementing flow control with the default values solved the problem.
Really easy to turn flow control on.

Interface config mode
(config-if) flowcontrol send on

We will be replacing the ASA with a 5555 that should be able to handle the traffic.

Fingers crossed.

Has anyone had interesting experiences with overrun or underrun on ASA interfaces?
How did it impact your end users and how did you resolve the issue?

[Akshay Rastogi · Accepted solution]

Hi there,

If enabling the Flow control resolved the issue then it means it is more of micro traffic burst which causing those overruns. When traffic comes faster than what ASA descriptor ring could process then traffic is being dropped on FIFO queue level.

Try calcultating if you are not oversubscribing the ASA. replacing ASA with ASA5555 might resolve the isuse. However if the issue is more of micro burst traffic, then ASA5555 might also get this issue.

Use link below to understanding the troubleshooting you could perform :

https://supportforums.cisco.com/document/47506/asa-oversubscription-interface-errors-troubleshooting

Hope it helps.

Regards,

Akshay Rastogi

[oyindamola15]

Hi Akshay,

Thank you for the detailed reponse.

I eventually opened a case with Cisco TAC. We may be oversubsribing the ASA.

It had a throughput of 1.1Gbps out of 1.5Gbps that it should be able to support.

The Engineer stated traffic burst as the cause of the issue. Enabling flow control solved the problem on the inside interface but the outside interface in now experiencing overruns as well.

[Akshay Rastogi]

Hi there,

1.1 out of 1.5 gbps is close to oversubscription and micro burst could make it worse. So as mentioned and confirmed by tac it is a traffic burst and flow control is the best option to tackle that.

I believe same thing could be there on Outside Interface as well. If possible, you could implement the same or look for oversubscription as you are close to that.

Regards,

Akshay Rastogi

Remember to mark the answer as correct if it answers your queries or rate the helpful posts.

[Rishabh Seth]

Hi,

If microbursts are seen in the network then you should check if it caused by legitimate traffic or not. There could be an option infected host generating bursts of traffic.

If microbursts are legit then I would say you should try smoothening of traffic using traffic shaping or rate limiting.

Flow control is more like a temporary fix, try to investigate the cause of microbursts as it affect any device

HTH.

RS

[oyindamola15]

Thanks for the response. Is there a tool you can recommend to help us find if the micoburst is caused by an infected host? Or to verify the traffic burst is legit?

[Akshay Rastogi]

Hi,

There is no specific tool as such. However you could take SPAN capture on switch for destination port as the port connected to ASA and analyze it through flow graph in Wireshark with tick to .01 or .001 sec.

Also you could check what host could be making a lot of connections, use the below command:

show local-host connection embryonic 500 | in host|count/limit

show local-host connection tcp 1000 | in host|count/limit

show local-host connection udp 1000 | in host|count/limit

These commands would show you hosts which are making lot of connections. Check if those hosts are allowed to make those many connections.

Hope it helps.

Regards,

Akshay Rastogi

[oyindamola15]

Thank s!

The commands helped. I was however able to verify that it was all legitimate traffic.

[Akshay Rastogi]

Hi,

That means you need to control the legitimate traffic and if they are all suppose to make these many connections and the way they are sending traffic, then you are already using the flow control so could go through the same or try policing or shapping.

Regards,

Akshay Rastogi