ASA logging queue

[corey]

I'm having an issue where our syslog server does not appear to be getting all of the data that we expect it to get from a couple of our ASA's.  The ASA's that are syslogging properly show "Current 0 msg on queue, 512 msgs most on queue" while the problematic ones usually have 300-400 "msg on queue".  I have tried to raise the "logging queue length limit" to 1024 on the problem ASA's, but that didn't help.  I also toned down the logging levels, as they were all at "debugging" but that did not help either.  These are very high traffic internal firewalls, so they are a lot busier than the 0 msg firewalls, but I'm thinking 300-400 messages in queue sounds too high.

Here's the output of a show logging settings:

Syslog logging: enabled
    Facility: 20
    Timestamp logging: disabled
    Standby logging: enabled
    Debug-trace logging: disabled
    Console logging: level notifications, 86410176 messages logged
    Monitor logging: level notifications, 86410174 messages logged
    Buffer logging: level notifications, 86410176 messages logged
    Trap logging: level debugging, facility 20, 86485505 messages logged
        Logging to prodinside-v364 syslogserver errors: 52467  dropped: 2382326
    History logging: disabled
    Device ID: disabled
    Mail logging: disabled
    ASDM logging: level informational, 86472362 messages logged

Any ideas as to what I can do to lower the size of my message queues?

Thanks!

[Kureli Sankar · Accepted solution]

Pls. remove console logging.

Issue "sh run logg"

You can remove monitor and console logg

conf t

no logging monitor

no logging console

once done check it again.

-KS

[Magnus Mortensen · Accepted solution]

Corey,

     To follow up on what Kureli mentioned, the biggest issue will be the console logging. When you enable console logging you force the syslog process to rate-limit the generation of syslogs such that they would not overwhelm the slow Serial link (console). Depending on the rate of syslogs generated by your ASA, the scant 9200 baud rate of the console gets overrun quickly and as a result logs have to be queued up and subsequently dropped.

     The only time you should be using console logging is if you have a host connected to the console and require seeing syslogs on that serial link. Even then, you must make sure the syslog rate is very low otherwise logs will be dropped by design.

- Magnus

[corey]

Thanks for the replies.  I have removed the console and monitor logging, but the issue still persists.  Here's the output of "sh run logg" after I removed console/monitor logging:

logging enable
logging standby
logging console notifications
logging monitor notifications
logging buffered notifications
logging trap debugging
logging asdm debugging
logging queue 1024
logging host prodinside-v364 syslogserver1
logging host prodinside-v364 syslogserver2
logging host prodinside-v364 syslogserver3

I issued a "no logging enable", waited for the queue to hit zero, then "logging enable" and the queue immediately started to grow and was up to around 300 again within about 20 seconds.  So I removed a few other settings, now it looks like this:

logging enable
logging buffered notifications
logging trap debugging
logging asdm debugging
logging queue 1024
logging host prodinside-v364 syslogserver1

and I still have over 300 messages queued (after disabling and enabling logging). Any other ideas?

This is part of a failover/dual-context pair if that matters.

[corey]

Just figured it out...

I removed the "logging standby" on the paired ASA and the queue on both immediately dropped to zero.  What will I be missing out on by not doing logging to the standby context/asa?

[Kureli Sankar]

Logging standby causes the standby unit also to send syslogs to the syslog server.

This will almost double the amount of syslogs that the syslog server will see as both units will send logs.

We do this for troubleshooting purpose just to see what the sec/standby unit sent to the syslog server during the time of the problem.

This is not on by default.

-KS