Troubleshooting Event and Session Logging
The recommended troubleshooting task flow when troubleshooting remote logging is as follows:
- For remote logging, verify mutual connectivity between the security appliance and the server using ping, traceroute, or similar tools.
- If you are using a TCP syslog server with a fail-closed policy (the default), use the show logging command (shown in Example 6-3) to determine if the host is reachable.
- Use show logging on the security appliance to determine the configuration of the event source. Verify logging filters to ensure that they are not filtering out desired event messages. You can also use the capture command to verify that events are actually being sent through security appliance interfaces. On the remote log destination, view stored logs and consider running a network analyzer to determine if events are arriving properly at the destination.
- Finally, there could be a performance problem at the security appliance that prevents it from sending messages to a destination. Use show logging queue (detailed in the next section) to examine the logging queue length and any drops, to determine if such a problem exists.
Troubleshooting Commands
Oversubscription of the logging queue indicates local performance issues. If you encounter oversubscription, consider logging less, rate-limiting a logging destination, tuning the logging queue, or using alternative logging methods such as NetFlow.
Example 6-5 shows the use of the show logging queue command to look for performance issues. A large number of discarded event messages is indicative of a logging subsystem performance problem.
Example 6-5. Verifying Logging Queue Performance
FIREWALL# show logging queue
Logging Queue length limit : 512 msg(s)
412366 msg(s) discarded due to queue overflow
10 msg(s) discarded due to memory allocation failure
Current 216 msg on queue, 512 msgs most on queue
The logging queue is where messages wait to be dispatched to their destinations. This queue is 512 messages long by default, but can be made larger or smaller. Rare drops due to queue overflow might not be indicative of a serious problem. Frequent drops due to queue overflow is a sign that the security appliance is not able to keep up with the number of messages being generated, and cannot dispatch them all to their intended destinations. If this occurs, first consider extending the size of the logging queue, using rate-limiting or more efficient logging methods (such as NetFlow), and reducing the amount of information being logged.
You can use the logging queue command to extend the size of the queue. Valid values range from 0 to 8192 messages. The following command doubles the size of the queue from the default value of 512 to a new value of 1024:
FIREWALL (config)# logging queue 1024
If a TCP-based syslog server is being used as a destination, with a fail-closed policy, and the server is not reachable, this will be indicated in the output of the show logging command, and will also appear as a recurring syslog message in an available destination (such as Internal Buffer or ASDM):
Jan 03 2011 18:49:56 FIREWALL : %ASA-3-414003: TCP Syslog Server manage- ment:192.168.1.7/1470 not responding, New connections are denied based on logging permit-hostdown policy