impact of ASA debugging level logging

[lcaruso]

Hi,

Does running an ASA at debugging level logging 100% of the time impact CPU and or Memory?

Are there recommendations from cisco about not doing this?

We are having a discussion about ASA debugging level logging versus doing the same on routers. Of course you don't do that on routers except when absolutely needed, but the question is: can you do it on ASAs without impact.

Thanks.

[varrao]

Hi Icaruso,

Debugging level is only to be used for troubleshooting purpose because yes, it affects the memory and CPU of the ASA. If you already have high amount of traffic passing through the ASA then debugging level would definitely be an overload on the ASA. You should use a syslog server with informational or notificational level logging. Whenever you want to troubleshoot anything on the ASA, you can turn on debugging level and after that you shoudl turn it off.

Hope that helps.

Thanks,

Varun

[lcaruso]

Sorry if this was vauge. I've dealt with cisco products since the mid 1990's, so I'm fully cognizant of the significance of debugging impact in general and the common sense tradition of when it is to be employed.

Here's the real issue:

We are dealing with a well known MSSP who claims they need all of a client's ASA's turned up to debugging level for their logging analysis. We didn't think it was necessary. They claim it doesn't impact cpu and memory signigicantly and they are doing this on thousands of ASAs.

While I agree that an already loaded device is not going to do well with debugging level logging, I'm looking for a more rigourous response from cisco is one can be had. Is there any more information that can be disclosed, for example, about how busy an ASA would need to be in order for debugging level logging to be a operational issue?

That's really what I'm trying to get at here. Thanks.

[lcaruso]

Can someone from cisco please comment on this further? Thanks.

We are dealing with a well known MSSP who claims they need all of a  client's ASA's turned up to debugging level for their logging analysis.  We didn't think it was necessary. They claim it doesn't impact cpu and  memory signigicantly and they are doing this on thousands of ASAs.

While  I agree that an already loaded device is not going to do well with  debugging level logging, I'm looking for a more rigourous response from  cisco is one can be had. Is there any more information that can be  disclosed, for example, about how busy an ASA would need to be in order  for debugging level logging to be a operational issue?

That's really what I'm trying to get at here. Thanks.

[lcaruso]

Logging debugs to a syslog server is better than logging debugs to the ASA.  All would agree that logging debugs is not normal.

Here are rules of thumb to follow when choosing a severity level:

• If only firewall error conditions should be recorded and no one will regularly view the message logs, choose severity level 3 (errors).

• If you are primarily interested in seeing how traffic is being filtered by the firewall access lists, choose severity level 4 (warnings).

• If you need an audit trail of firewall users and their activity, choose severity level 5 (notifications).

• If you will be using a firewall log analysis application, you should choose severity level 6 (informational). This is the only level that produces      messages about connections that are created, as well as the time and data volume usage.

• If you need to use any debug command to troubleshoot something on the firewall, choose a destination with severity level 7 (debugging). You can use the logging debug-trace command to force debug output to be sent to a logging destination for later review. All Syslog messages      containing debug output use message ID 711001 at a default severity level of 7.

[Henry Pinera]

I was looking at this same issue for one of my customers and was surprised to find that MSSPs are telling customers that this is a safe practice.  In my experience with Unix/Linux systems I have always seen guidance to use debug level commands judiciously.  Now specific to ASA the guidance is also clear:

Usage Guidelines

Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use.

ASA command reference - debug

configuration guide for ASA: View debugging messages

[MHM Cisco World]

if your costumer need that we can at least make reduce log message ASA send, for example 
when your traffic hit ACL line it generate Log message, but if traffic hit again same ACL line the Log message will not generate, the ASA wait some time before regenerate log for same traffic hit same ACL line. 
I know this will not make huge different but It will help you at least for little to reduce CPU utilize.

https://www.globalknowledge.com/ca-en/resources/resource-library/articles/asa-acl-logging/