Number of cached deny-flows for ACL log has reached limit (4096)

[mykys]

Hi All,

WS-SVC-FWM-1 running FWSM Firewall Version 4.0(16)

While ago the device generated and sent following syslog messages:

Number of cached deny-flows for ACL log has reached limit (4096)

Is there any workaround for this issue?

Thanks,

Myky

[zachrhart@gmail.com · Accepted solution]

Hi Mykys,

I'd be happy to discuss the firewall error logging that generates that message with you! I'm not sure what the uptime is on that firewall, but by default each unique traffic flow that is denied by an ACE will be added to a cached list of tracked flows. This generally doesn't generate any problems unless something like a denial of service attack causes a huge number of ACE blocks to be cached, or you have a device with an extremely long uptime.

The firewall limits the maximum number of flows it caches to track. By default, the maximum number is based on the available memory. 4096 cached flows indicates that you have 64MB or more available memory for this purpose.

As for a workaround--what outcome are you looking for? By default, this message will appear every 5 minutes once the cache is full. There are no other symptoms, the firewall is simply alerting you that the cache memory is full. If you'd like to see the message less often, you can decrease the message interval with:

Firewall(config)#: access-list alert-interval seconds (1 to 3600 seconds)

You can also change the severity level of your logging buffer or track logging object using

Firewall# show logging setting

If you find that your logging buffer is filling up too quickly you may want to disable logging severity, or turn the "log" feature off on your deny statement ACLs. Setting up and pointing the firewall to a syslog server would also prevent the logging buffer from filling up and generating the error message.

If you simply wish to clear the logging buffer and start back at zero, reload the device or enter Firewall(config)clear logging buffer.

I've attached some related commands from the CLI configuration guide below

Related Commands

 Command Description

clear logging buffer	Clears the log buffer of all syslog messages that it contains.
logging buffer-size	Specifies log buffer size.
logging enable	Enables logging.
logging list	Creates a reusable list of message selection criteria.
logging savelog	Saves the contents of the log buffer to flash memory.

Please let me know if you have any other questions about this error message or would like more information about any of the steps I outlined.

Please rate and/or mark the question if you found my answer helpful!

Thank you!

-Zac

[mykys]

Thanks Zac,

Saying that l am looking for a workaround was not a correct term as it appears to be expected behaviour.

Cheers,

myky

[zachrhart@gmail.com]

Happy to help, Mykys!

Personally I'd just clear the log buffer every now and then but leave logging on at the default levels. If the alert resurfaces quickly you may want to start dumping the logs and see if you're getting attacked, but if it only crops up every now and then just clear the buffer when it fills up. I'm not compulsive enough to regularly dump logs or run a syslog server on my personal network, but I do like to leave a few red-flag alerts open on the devices to let me know if something needs my attention.

Thanks for rating! Glad I could help!

:)

-Zac

[morningfalcon]

Hello, I was getting this message a lot as well on my ASA firewall and found that clearing the log buffer had no effect. Eventually I found that one of my top ranking deny ACEs in my outside access rule set was set to log--albeit at a debug level. Disabling logging on that ACE dropped my cached deny flows to just under 250.

Here's before disabling logging on the ACE:

firewall# sh access-list | i cached ACL log
access-list cached ACL log flows: total 23795, denied 4096 (deny-flow-max 4096)

And after:

firewall# sh access-list | i cached ACL log
access-list cached ACL log flows: total 14542, denied 248 (deny-flow-max 4096)

Apparently when the firewall logs a rule hit it caches the flow (source and destination addresses, protocols, and ports) and then keeps track of additional hits for the next five minutes by default (time window is configurable on a rule-by-rule basis). If there are zero hits in that five minute window it removes the flow, otherwise it keeps it for another five minutes. So if you have a deny rule configured for logging that gets a lot of activity from a lot of different sources (a deny all rule on your outside interface, for example) then this cache can fill up rather quickly.

Hopefully that helps anyone else that happens to come across this post.

Cheers,

~morningfalcon

PS - Apologies for reviving an old thread, btw. It was difficult finding this info online otherwise I would have left it alone.