High Number of Discards from ASA-5505 Interfaces

we have a lot of ACLs spread throughout and a majority of our 'discards' on interfaces are due to this (ACL discards), especially on our vpn links.

it's too bad we can't associate these two for filtering and get what is a true discard.

i guess the MIB read by Solarwinds is the answer whether it is dropped by ACLs, errors, or high traffic use. most gigabit interfaces in our environment are no where near high util to cause a discard.

my two-cents...

lchance,

     thanks for the reply.  i believe it to be related to the VACL as well.  anyone else have some insight?

thanks

I'd like to add that we have the same problem on our access points. 

One of our offices is in a shared building so we log a ton of "discards".  In reality, most of these are non-company laptops associating with our APs because their laptops attempt connections alphabetically instead of going right to their own company's SSID.

We happen to have numerous ASA 5520's in our enterprise and some of our contexts are showing on Orion as having receive discards.  Orion shows a large amount of rec discards, but the ASA shows a smaller amount of general discards on the interface.  Our Firewall tech is asking me to pose some questions:

After looking through all manner of statisitics and information within the ASA itself I can’t find anything that indicates a problem resulting in these discards. Then I wondered if Orion would consider an inbound firewall drop (a packet that doesn’t match a permit statement in an inbound ACL) a “receive discard”. Also can you ask if there is any way to find out more information about the cause of a receive discard for an ASA in particular?  Orion shows a much larger # of discards than the actual ASA does, so could it be possible its reading an different MIB or something.

Any input on this would be great because he cannot seem to see any reason for discards or that its impacting the interface or ASA at all.  Thanks.

I have noticed this on our VPN devices as well.  We have VPN concentrators that have upwards of about 500 people at any one time on them we they ALWAYS have high numbers of discards.  There are no ACLs running here since they do VPN only, no firewall function.  So my thought was always it was packets that the device expected to be encrypted or not encrypted and when it got what it did  not expect it drops it and flips the counter.  If I watch logs I see a lot of "expected this and got that" type of thing.

So long story short I have considered it harmless and expected on a VPN device.

If anyone of you found the reason or solution, let me know.

I have a same situation with 5505.

I too am seeing this issue - is there a solution out there?

Are these failed association attempts logged as receive discards, transmit, or both?

Thank you,

Dustin