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. On Sun, Nov 20, 2011 at 3:33 PM, Jimmy Hess <mysidia@gmail.com> wrote:
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
On Sun, Nov 20, 2011 at 6:42 AM, Joe Happe <Joe.Happe@archlearning.com> wrotewi: that allows a tcp syslog to fail and not block traffic.
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
-- -JH