Cisco asr error overrun

Всем доброго дня!
Связь через DMVPN+IPSEC . На ядре 2 роутера, один primary — по нему течет весь трафик, второй пока не используем (secondary).
На филиальном spoke-роутере теряются пакеты при пинге на primary роутер . Так же, время от времени, на spoke, дергается динамическая маршрутизация OSPF(теряет смежность с primary router).По интернету от spoke на primary — пакеты не пропадают. Ночью, когда трафика почти нет — и в тунеле все хорошо, никаких провалов нет.
Хочу заметить, что пакеты пропадают только на primary . Secondary отвечает без провалов.
Вчера перевел весь трафик на spoke с primary , на secondary. Появились провалы до secondary, а primary пингуется без провалов. Провалы появляются только в канале, по которому идет основной crypto трафик .
Еще замечу что, пинг с проблемного spoke на соседний spoke( не ядро) идет без потерь в час-пики.
С ядром тоже все нормально, пинги между другими spoke в обе стороны без потерь.
Снимал IPSEC- ситуация не изменилась.
Процессор — 60%. Криптуха на 30мбитс + 10 мегабит не криптованного трафика. Роутер cisco2921
Изменение маршрутов не помогло, расширение канала до 80 мбит не помогло.

Интерфейс в сторону провайдера, клирнул статистику за 5 минут до копирования на форум.

Не понимаю в чем проблема.Направьте плз. Мб буферы как-то править?

Источник

Troubleshoot Interface Overrun caused by Distributed Etherchannel

Available Languages

Download Options

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

EtherChannel bundle is used to provide high bandwidth interconnects. This article discusses a limitation which applies to Cisco EtherChannels on Catalyst 6500 switches running Supervisor 720 with PFC3A, PFC3B or PFC3BXL that can cause overrun to increment on Etherchannel member interfaces. This limitation is related to Layer 2 Forwarding Engine and hence applies only to layer 2 EtherChannels.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on Cisco Catalyst 6500 Series switches that run Supervisor Engine 720. WS-X6704-10GE has been used in this lab setup.WS-X6704-10GE is a Catalyst 6500 module with no oversubscription & has 2 fabric channel connections of 20 Gbps each.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Problem

A Catalyst 6500 might experience interface overrun when a Layer 2 Distributed Etherchannel (DEC) is configured. DEC is an etherchannel across 2 or more Distriubuted Forwarding Card (DFC) modules. An Etherchannel with 2 member interfaces connected on the same linecard but on different fabric channels is not considered a DEC .

Overrun counter accounts number of times the receiver hardware was unable to hand received data to a hardware buffer. In other words, the input rate of traffic exceeded the ability of the receiver to handle the data.

In certain cases, DFC provides the capability to recirculate the packets. Recirculation can be used to perform additional lookups in the ACL or QoS Ternary Content Addressable memory (TCAM), the NetFlow table, or the Forwarding Information Base (FIB) TCAM table. Packet recirculation occurs only on a particular packet flow; other packet flows are not affected. The rewrite of the packet occurs on the modules; the packets are then forwarded back to the Policy Feature Card (PFC) for additional processing.

When using a layer 2 DEC, packet recirculation at ingress module is required during packet forwarding. Recirculation is also required for multi-module L2 EtherChannel if Catalyst 6500 is running in flow-through mode along with 3B/3BXL PFC mode.

More information about flow-through mode is available here.

Overrun counter can start incrementing when the fabric utilization reaches about 50%.

Troubleshoot & Verify

1) Find out the member interfaces in the Etherchannel experiencing incrementing overruns.

2) Verify input rate and overrun counters on member interfaces.

3) Find out the modules on which these interfaces are present.

4) Find out the fabric interface utilization corresponding to these modules.

Solution

1) Configure a non distributed Etherchannel which is not affected by this limitation.

To validate this theory, an Etherchannel was configured on interfaces on same module (non DEC) and it was observed that at same packet rate as above, interfaces did not see any overruns incrementing. This can be a workaround to bypass this problem.

2) Use Catalyst 6500 switch in PFC 3C/3CXL mode in case L2 DEC is required.

Note: DFC hardware upgrade would be required in case existing modules are running DFC3A/ DFC3B/ DFC3BXL.

3) Upgrade IOS version if your design and configuration applies to the conditions in CSCti23324.

This bug fix relaxes the recirculation requirement for L2 DEC or multi-module EtherChannel for Catalyst 6500 switches with 67xx modules only. This bug is resolved in Cisco IOS release 12.2(33)SXJ1 and later. Be aware of following points that apply to this bug.

a) The bug fix relaxes the recirculation requirement for L2 DEC or multi-module EC for Catalyst 6500 switches 67xx modules only. In case the Catalyst 6500 switch has at least one L2 DEC across any older DFC module (e.g. 6516/6816) or combination of 67xx and 6516/6818 module, recirculation will be imposed for all L2 DECs configured in the system. In case Catalyst 6500 switch has any older module and is configured with L2 DEC on 67xx modules only, recirculation will not be imposed.

b) Presence of all 67xx line cards is not enough to remove the recirculation requirement for DECs. For example, if you have a DEC across 2 6704 DFCs and another port-channel configured on a 6748 CFC, the system will check the forwarding engine of supervisor (for the CFC module) and start using recirculation.

c) For VS-SUP720-10G, this bug fix does not work in scenarios where at least one port of L2 DEC is on CFC linecard / supervisor. In this scenario recirculation still happens. In addition, adjacency is not upgraded and recirculation is still in place even if you remove supervisor/CFC enabled port from the port-channel. In such scenario, reload is required to reprogram the hardware and removing & reconfiguring port-channel / redundancy switchover / removing L2 VLAN, etc. do not help.

Источник

Troubleshoot ASA Interface Overrun Counter Errors

Available Languages

Download Options

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

This document describes the «overrun» error counter and how to investigate performance issues or packet loss problems on the network. An administrator might notice errors reported in the show interface command output on the Adaptive Security Appliance (ASA).

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Problem

The ASA interface error counter «overrun» tracks the number of times that a packet was received on the network interface, but there was no available space in the interface FIFO queue to store the packet. Thus, the packet was dropped. The value of this counter can be seen with the show interface command.

Example output that displays the problem:

[an error occurred while processing this directive]

In the example above, 2881 overruns were observed on the interface since the ASA booted up or since the command clear interface was entered in order to clear the counters manually.

Causes of Interface Overruns

Interface overrun errors are usually caused by a combination of these factors:

• Software level — The ASA software does not pull the packets off of the interface FIFO queue fast enough. This causes the FIFO queue to fill up and new packets to be dropped.
• Hardware level — The rate at which packets come into the interface is too fast, which causes the FIFO queue to fill before the ASA software can pull the packets off. Usually, a burst of packets causes the FIFO queue to fill up to maximum capacity in a short amount of time.

Steps to Troubleshoot the Cause of Interface Overruns

The steps to troubleshoot and address this problem are:

1. Determine if the ASA experiences CPU hogs and if they contribute to the problem. Work to mitigate any long or frequent CPU hogs.
2. Understand the interface traffic rates and determine if the ASA is oversubscribed due to the traffic profile.
3. Determine if intermittent traffic bursts cause the problem. If so, implement flow control on the ASA interface and adjacent switchports.

Potential Causes and Solutions

CPU on the ASA is Periodically Too Busy to Process Incoming Packets (CPU Hogs)

The ASA platform processes all packets in software and uses the main CPU cores that handle all system functions (such as syslogs, Adaptive Security Device Manager connectivity, and Application Inspection) in order to process incoming packets. If a software process holds the CPU for longer than it should, the ASA records this as a CPU hog event since the process «hogged» the CPU. The CPU hog threshold is set in milliseconds, and is different for each hardware appliance model. The threshold is based on how long it could take to fill the interface FIFO queue given the CPU power of the hardware platform and the potential traffic rates the device can handle.

CPU hogs sometimes cause interface overrun errors on single-core ASAs, such as the 5505, 5510, 5520, 5540, and 5550. The long hogs, that last for 100 milliseconds or more, can especially cause overruns to occur for relatively low traffic levels and non-bursty traffic rates. The problem does not impact multi-core systems as much, since other cores can pull packets off of a Rx ring if one of the CPU cores is hogged by a process.

A hog that lasts more than the device threshold causes a syslog to be generated with id 711004, as shown here:

Feb 06 2013 14:40:42: %ASA-4-711004: Task ran for 60 msec, Process = ssh, PC = 90b0155, Call stack = Feb 06 2013 14:40:42: %ASA-4-711004: Task ran for 60 msec, Process = ssh, PC = 90b0155, Call stack = 0x090b0155 0x090bf3b6 0x090b3b84 0x090b3f6e 0x090b4459 0x090b44d6 0x08c46fcc 0x09860ca0 0x080fad6d 0x080efa5a 0x080f0a1c 0x0806922c

CPU hog events are also recorded by the system. The output of the show proc cpu-hog command displays these fields:

• Process — the name of the process that hogged the CPU.
• PROC_PC_TOTAL — the total number of times that this process hogged the CPU.
• MAXHOG — the longest CPU hog time observed for that process, in milliseconds.
• LASTHOG — the amount of time the last hog held the CPU, in milliseconds.
• LASTHOG At — the time the CPU hog last occurred.
• PC — the program counter value of the process when the CPU hog occurred. (Information for the Cisco Technical Assistance Center (TAC))
• Call stack — the call stack of the process when the CPU hog occurred. (Information for the Cisco TAC)

This example shows the show proc cpu-hog command output:

[an error occurred while processing this directive]

The ASA SSH process held the CPU for 119ms on 12:25:33 EST June 6th 2012.

If overrun errors continually increase on an interface, check the output of the show proc cpu-hog command in order to see if CPU hog events correlate with an increase in the interface overrun counter. If you find that the CPU hogs contribute to the interface overruns errors, it is best to search for bugs with the Bug Toolkit, or raise a case with the Cisco TAC. The output of the show tech-support command also includes the show proc cpu-hog command output.

Traffic Profile Processed Periodically Oversubscribes the ASA

Dependent upon on the traffic profile, the traffic that flows through the ASA might be too much for it to handle and overruns might occur.

The traffic profile consists of (among other aspects):

• Packet size
• Inter-packet gap (packet rate)
• Protocol — some packets are subjected to application inspection on the ASA and require more processing than other packets

These ASA features can be used in order to identify the traffic profile on the ASA:

• Netflow — the ASA can be configured to export NetFlow version 9 records to a NetFlow collector. This data can then be analyzed to understand more about the traffic profile.

• SNMP — utilize SNMP monitoring in order to track the ASA interface traffic rates, CPU, connection rates, and translation rates. The information can then be analyzed in order to understand the traffic pattern and how it changes over time. Try to determine if there is a spike in traffic rates that correlates to an increase in the overruns, and the cause of that traffic spike. There have been cases in the TAC where devices on the network misbehave (due to misconfiguration or virus infection) and generate a flood of traffic periodically.

Intermittent Packet Bursts Oversubscribe the ASA Interface FIFO Queue

A burst of packets that arrive on the NIC could cause the FIFO to become filled before the CPU can pull the packets off of it. There usually is not much that can be done in order to solve this problem, but it can be mitigated by the use of QoS in the network to smooth out the traffic bursts, or flow control on the ASA and the adjacent switchports.

Flow control is a feature that allows the ASA’s interface to send a message to the adjacent device (a switchport for example) in order to instruct it to stop sending traffic for a short amount of time. It does this when the FIFO reaches a certain high water mark. Once the FIFO has been freed up some amount, the ASA NIC sends a resume frame, and the switchport continues to send traffic. This approach works well because the adjacent switchports usually have more buffer space and can do a better job buffering packets on transmit than the ASA does in the receive direction.

You can try to enable captures on the ASA to detect the traffic micro-bursts, but usually this is not helpful since the packets are dropped before they can get processed by the ASA and added to the capture in memory. An external sniffer can be used to capture and identify the traffic burst, but sometimes the external sniffer can be overwhelmed by the burst as well.

Enable Flow Control to Mitigate Interface Overruns

The flow control feature was added to the ASA in version 8.2(2) and later for 10GE interfaces, and version 8.2(5) and later for 1GE interfaces. The ability to enable flow control on ASA interfaces that experience overruns proves to be an effective technique to prevent packet drop occurences.

(Diagram from Andrew Ossipov’s Cisco Live Presentation BRKSEC-3021)

Note that «output flow control is on» means that the ASA sends flow control pause frames out the ASA interface towards the adjacent device (the switch). «Input flow control is unsupported» means that the ASA does not support the reception of flow control frames from the adjacent device.

Flow Control Sample Configuration:

[an error occurred while processing this directive]

Источник

Adblock
detector

I’m trying to pinpoint a reason I’m seeing intermittent bursts of overrun errors on a ASR1002. Quite large bursts as well up to around 400,000 in a short 10 minute window.

The ASR1002 has the esp-10 and 2 x 10Gb line cards. IT just has one 10Gb uplink and one 10Gb to our supplier on which we have a few hundred customers.

Anything you look at online says that overrun errors are caused by the router receiving too much traffic that it can’t process in time. We’ve been monitoring the traffic very carefully and we are averaging around 1.1Gbps to 1.5Gbps through the device.

Now it’s possible there is some very bursty traffic causing this but we haven’t been able to spot it with Solarwinds or netflow enabled on the router. But to be honest even if it was a sudden microburst I don’t think it would take it above the routers capacity and all the customers which hang off the router have designated bandwidths so they could only burst up to their allocation. Still it’s possible and something we are looking at.

As we couldn’t find what was responsible our next thoughts were:

Faulty optics,
Faulty Line cards,
Faulty fibre, and finally faulty router.

They’ve all been replaced and still we see the overrun errors. It happens maybe 4 times a day (some days not at all) and over a day we can run up to around 1 to 2 million overrun errors.

I’ve got a Cisco TAC case ongoing but they are being pretty useless with finding the cause. They keep basically reading off the Cisco literature and advising that the router is hitting capacity despite them enabling an event manager script to capture traffic on the router and it not actually finding anything of significance.

So i’ve bounced it back to them several times and it’s still in their hands.

One thing I have noticed which may not be of significance is when I compare this ASR1002’s 10Gb link to our provider with our others is that this 10Gb has ‘route cache’ counters incrementing. Not a huge amount, about 5 a second but I don’t see this happen on any of our other ASR routers which have identical setups and similar throughputs.

All my reading on the route cache doesn’t really point me to an issue but I can’t figure out why this one would be incrementing. We’ve gone down the line that maybe our 10Gb provider is having issues and it’s causing buffers to fill up between our ASR1002 and their equipment which then causes the overruns.

Our last direction we are looking into is if someone is sending a certain type of traffic through the ASR at certain times of day which is causing issues. This is where we’ve enabled NETFLOW to try to see if there is a pattern to what data is going through the ASR when they netflow events occur.

So far not pattern that we can see. We see some high amounts of ESP traffic going through but nothing crazy or of concern.

Looking see if any of you guys/gals may have experienced anything similar? Thanks

Introduction

This document describes the «overrun» error counter and how to investigate performance issues or packet loss problems on the network. An administrator might notice errors reported in the show interface command output on the Adaptive Security Appliance (ASA).

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Problem

The ASA interface error counter «overrun» tracks the number of times that a packet was received on the network interface, but there was no available space in the interface FIFO queue to store the packet. Thus, the packet was dropped. The value of this counter can be seen with the show interface command.

Example output that displays the problem:

ASA# show interface GigabitEthernet0/1
Interface GigabitEthernet0/1 "inside", is up, line protocol is up
  Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
	Full-Duplex(Full-duplex), 1000 Mbps(1000 Mbps)
	Input flow control is unsupported, output flow control is off
	MAC address 0026.0b31.0c59, MTU 1500
	IP address 10.0.0.113, subnet mask 255.255.0.0
	580757 packets input, 86470156 bytes, 0 no buffer
	Received 3713 broadcasts, 0 runts, 0 giants       
	2881 input errors, 0 CRC, 0 frame, 2881 overrun, 0 ignored, 0 abort
	0 pause input, 0 resume input
	0 L2 decode drops
	905828 packets output, 1131702216 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/202)

[an error occurred while processing this directive]

In the example above, 2881 overruns were observed on the interface since the ASA booted up or since the command clear interface was entered in order to clear the counters manually.

Causes of Interface Overruns

Interface overrun errors are usually caused by a combination of these factors:

• Software level — The ASA software does not pull the packets off of the interface FIFO queue fast enough. This causes the FIFO queue to fill up and new packets to be dropped.
• Hardware level — The rate at which packets come into the interface is too fast, which causes the FIFO queue to fill before the ASA software can pull the packets off. Usually, a burst of packets causes the FIFO queue to fill up to maximum capacity in a short amount of time.

Steps to Troubleshoot the Cause of Interface Overruns

The steps to troubleshoot and address this problem are:

1. Determine if the ASA experiences CPU hogs and if they contribute to the problem. Work to mitigate any long or frequent CPU hogs.
2. Understand the interface traffic rates and determine if the ASA is oversubscribed due to the traffic profile.
3. Determine if intermittent traffic bursts cause the problem. If so, implement flow control on the ASA interface and adjacent switchports.

Potential Causes and Solutions

CPU on the ASA is Periodically Too Busy to Process Incoming Packets (CPU Hogs)

The ASA platform processes all packets in software and uses the main CPU cores that handle all system functions (such as syslogs, Adaptive Security Device Manager connectivity, and Application Inspection) in order to process incoming packets. If a software process holds the CPU for longer than it should, the ASA records this as a CPU hog event since the process «hogged» the CPU. The CPU hog threshold is set in milliseconds, and is different for each hardware appliance model. The threshold is based on how long it could take to fill the interface FIFO queue given the CPU power of the hardware platform and the potential traffic rates the device can handle.

CPU hogs sometimes cause interface overrun errors on single-core ASAs, such as the 5505, 5510, 5520, 5540, and 5550. The long hogs, that last for 100 milliseconds or more, can especially cause overruns to occur for relatively low traffic levels and non-bursty traffic rates. The problem does not impact multi-core systems as much, since other cores can pull packets off of a Rx ring if one of the CPU cores is hogged by a process.

A hog that lasts more than the device threshold causes a syslog to be generated with id 711004, as shown here:

Feb 06 2013 14:40:42: %ASA-4-711004: Task ran for 60 msec, Process = ssh, PC = 90b0155, Call stack = Feb 06 2013 14:40:42: %ASA-4-711004: Task ran for 60 msec, Process = ssh, PC = 90b0155, Call stack = 0x090b0155 0x090bf3b6 0x090b3b84 0x090b3f6e 0x090b4459 0x090b44d6 0x08c46fcc 0x09860ca0 0x080fad6d 0x080efa5a 0x080f0a1c 0x0806922c

CPU hog events are also recorded by the system. The output of the show proc cpu-hog command displays these fields:

• Process — the name of the process that hogged the CPU.
• PROC_PC_TOTAL — the total number of times that this process hogged the CPU.
• MAXHOG — the longest CPU hog time observed for that process, in milliseconds.
• LASTHOG — the amount of time the last hog held the CPU, in milliseconds.
• LASTHOG At — the time the CPU hog last occurred.
• PC — the program counter value of the process when the CPU hog occurred. (Information for the Cisco Technical Assistance Center (TAC))
• Call stack — the call stack of the process when the CPU hog occurred. (Information for the Cisco TAC)

This example shows the show proc cpu-hog command output:

ASA# 

show proc cpu-hog

Process:    ssh, PROC_PC_TOTAL: 1, MAXHOG: 119, LASTHOG: 119
LASTHOG At: 12:25:33 EST Jun 6 2012
PC:         0x08e7b225 (suspend)

Process:    ssh, NUMHOG: 1, MAXHOG: 119, LASTHOG: 119
LASTHOG At: 12:25:33 EST Jun 6 2012
PC:         0x08e7b225 (suspend)
Call stack: 0x08e7b225 0x08e8a106 0x08e7ebf4 0x08e7efde 0x08e7f4c9 0x08e7f546 0x08a7789c
            0x095a3f60 0x080e7e3d 0x080dcfa2 0x080ddf5c 0x0806897c

CPU hog threshold (msec): 10.240
Last cleared: 12:25:28 EST Jun 6 2012
ASA# 

[an error occurred while processing this directive]

The ASA SSH process held the CPU for 119ms on 12:25:33 EST June 6th 2012.

If overrun errors continually increase on an interface, check the output of the show proc cpu-hog command in order to see if CPU hog events correlate with an increase in the interface overrun counter. If you find that the CPU hogs contribute to the interface overruns errors, it is best to search for bugs with the Bug Toolkit, or raise a case with the Cisco TAC. The output of the show tech-support command also includes the show proc cpu-hog command output.

Traffic Profile Processed Periodically Oversubscribes the ASA

Dependent upon on the traffic profile, the traffic that flows through the ASA might be too much for it to handle and overruns might occur.

The traffic profile consists of (among other aspects):

• Packet size
• Inter-packet gap (packet rate)
• Protocol — some packets are subjected to application inspection on the ASA and require more processing than other packets

These ASA features can be used in order to identify the traffic profile on the ASA:

• Netflow — the ASA can be configured to export NetFlow version 9 records to a NetFlow collector. This data can then be analyzed to understand more about the traffic profile.

• SNMP — utilize SNMP monitoring in order to track the ASA interface traffic rates, CPU, connection rates, and translation rates. The information can then be analyzed in order to understand the traffic pattern and how it changes over time. Try to determine if there is a spike in traffic rates that correlates to an increase in the overruns, and the cause of that traffic spike. There have been cases in the TAC where devices on the network misbehave (due to misconfiguration or virus infection) and generate a flood of traffic periodically.

Intermittent Packet Bursts Oversubscribe the ASA Interface FIFO Queue

A burst of packets that arrive on the NIC could cause the FIFO to become filled before the CPU can pull the packets off of it. There usually is not much that can be done in order to solve this problem, but it can be mitigated by the use of QoS in the network to smooth out the traffic bursts, or flow control on the ASA and the adjacent switchports.

Flow control is a feature that allows the ASA’s interface to send a message to the adjacent device (a switchport for example) in order to instruct it to stop sending traffic for a short amount of time. It does this when the FIFO reaches a certain high water mark. Once the FIFO has been freed up some amount, the ASA NIC sends a resume frame, and the switchport continues to send traffic. This approach works well because the adjacent switchports usually have more buffer space and can do a better job buffering packets on transmit than the ASA does in the receive direction.

You can try to enable captures on the ASA to detect the traffic micro-bursts, but usually this is not helpful since the packets are dropped before they can get processed by the ASA and added to the capture in memory. An external sniffer can be used to capture and identify the traffic burst, but sometimes the external sniffer can be overwhelmed by the burst as well.

Enable Flow Control to Mitigate Interface Overruns

The flow control feature was added to the ASA in version 8.2(2) and later for 10GE interfaces, and version 8.2(5) and later for 1GE interfaces. The ability to enable flow control on ASA interfaces that experience overruns proves to be an effective technique to prevent packet drop occurences.

Refer to the flow control feature in the Cisco ASA 5500 Series Command Reference, 8.2 for more information.

(Diagram from Andrew Ossipov’s Cisco Live Presentation BRKSEC-3021)

Note that «output flow control is on» means that the ASA sends flow control pause frames out the ASA interface towards the adjacent device (the switch). «Input flow control is unsupported» means that the ASA does not support the reception of flow control frames from the adjacent device.

Flow Control Sample Configuration:

interface GigabitEthernet0/2
 

flowcontrol send on

 nameif DMZ interface
 security-level 50
 ip address 10.1.3.2 255.255.255.0
!

[an error occurred while processing this directive]

Related Information

• ASA 8.3 and Later: Monitor and Troubleshoot Performance Issues
• Cisco Live Presentation «Maximizing Firewall Performance» — This presentation outlines the architecture of the various ASA platforms, and includes information about performance and tuning. For access to this presentation, log in to Ciscolive!365 and search for the presentation number BRKSEC-3021.
• Cisco TAC Security Podcast Episode #7 «Monitoring Firewall Performance» — This podcast episode features a discussion of techniques and methods to monitor firewall performance and identify performance problems.

• Technical Support &  Documentation — Cisco Systems

I have an ASA5520 running version 8.2.5.  I am receiving a lot of input errors which are all overruns.  Its doesn’t seem to be affecting performance, but I would like to fix it.  To help troubleshoot the problem I configured netflow on the ASA and have it send information to my solarwinds netflow collector.  I have a 100Mbps internet circuit, and over the last month, I’ve only hit 50Mbps once, so it can’t be an over subscription issue as I have lots of bandwidth to spare.  Usually I’m well below 50Mbps.  Now I’m getting the overruns on the inside interface.  It is configured at 1GB and the switch that connects to it is also 1GB (Cisco 3560G).  I’m reading that it could be bursts of traffic.  How do I find out where these bursts of traffic are coming from and begin to troubleshoot?  I could enable flow control, but doesn’t that just put a bandage on the problem?  I would really like to know what is happening.  Cisco TAC’s solution was to enable flow control, they wouldn’t really go farther than that, and basically said they will do not more troubleshooting until flow control is enabled.  Is this a  viable solution?  Any Suggestions or advice from some who has had a similar problem would be  greatly appreciated.  Thanks!