ASA log viewer

I'd like to fully search on an 'column', a la 'ladder logic' style.,

>as well as have the data presented in an orderly well-defined fashion.

Yes, Splunk.

See:
http://www.networkworld.com/reviews/2011/092611-splunk-test-250836.html

for a recent Network World test of Splunk which may help.

jms

Completely agree with splunk for log searching / analysis, even has some ASA/PIX modules. Please note, unless something has changed that I completely missed, an ASA/PIX will stop forwarding user traffic if it is configured for tcp syslogs and the connection breaks. (no more disk, network issue, etc) This is based on the premise that a system cannot be considered secure if the audit trail is unavailable, and tcp syslogging(vs udp) is usually used to make sure you don't miss an entry due to a dropped packet. Something that dates back to the old C2 security standard??(not sure of the current version). Typically this requires admin intervention (by design) to clear the condition. If you use udp for syslog the ASA won't be in this mode, and you won't block traffic if syslog fails. With that said, there may be a command I'm unaware of that allows a tcp syslog to fail and not block traffic.

~jdh

The logging host command enables a secure connection via TLS, and to configure
use of a TCP port for logging.

 e\.g\.,  interface\_name syslog\_ip\[tcp/port\] \[emblem format\] \[secure\]

Also, when you do a sho log, do you have the following set?

 Deny Conn when Queue Full: disabled

I think it was ASA 8.3 that began to provide an option to NOT cease
functionality when tcp syslog server was unreachable. In ASDM, it is a
checkbox at the bottom of the logging servers config section.

I'll go back to check that option about queue size. Thanks for the hint!

Yes.
logging permit-hostdown

However, if you don't need to refuse connections when TCP syslog
fails, then you don't need 100% of your syslog messages, you should
use UDP syslog for performance.

TCP just makes sure you will get all syslog messages between time A
and time B or none of them.
If there are WAN issues, there are many cases where one would prefer
SOME syslog messages, with an understanding that the network
bottleneck means messages are being lost, rather than few/no syslog
messages to help debug the issue

I guess this depends on how aggressive the TCP reconnection algorithm is
vs. the packet loss of UDP...

On the other hand, does ASA support "buffering" of syslog messages while
TCP is down? I believe on some IOS platforms, with the right syslog
options, it has the capability of queuing and delivering syslog messages
generated during a period of network outage once the syslog session is
re-established. Does ASA do this, or discard them?

Now on the other hand, never route two ASAs to one another (IE: summary
route design). They don't decrement TTL by default. I had one case where
a loopy route got installed and the traffic just kept ping-ponging back and
forth maxing the port. The brutal part was not the pegged port, but rather
the many megabits of udp syslog that resulted that the WAN link couldn't
handle. decrement-ttl and logging rate-limit are now on as a result. On
the other hand, TCP syslog would have handled it much better without a
denial of service condition.

Except you can't do syslog via TLS with UDP. :-/