2

I'm planning to move from UDP-Syslog to TCP-Syslog on some Cisco switches (for example WS-C3560X-24P with 15.0(2)SE9 installed). But in Cisco documentation I'm not able to find any hint on what happens if a syslog server has a "problem" or is not available? Does the switch queue the syslog messages? Or does it drop the messages? Could it be service affecting, if a "buffer" runs full with syslog messages on the device?

Any help?

Thank you in advance!

Improve this question
4
  • Why don't you test it in a lab environment? Or GNS? Why are you moving to TCP Syslog?
    – Kevin Bowen
    Commented Mar 14, 2018 at 9:19
  • We move to TCP because of the reliabilty. I think a lab-test cannot reproduce all errors that someone might have seen in real life and maybe someone knows where to find some documentation from cisco?
    – flo
    Commented Mar 14, 2018 at 9:20
  • Be aware that UDP over local area networks of switches is extremely reliable (ask yourself where the packet loss would come from in your network). I often prefer the simplicity of the UDP delivery, coupled with multiple log targets on different interfaces, with numbered messages. It depends what your overall parameters are whether you'd rather have the TCP retries or the multiple logs to get your reliability.
    – jonathanjo
    Commented Mar 14, 2018 at 13:18
  • Yes, you're right. But I'd prefer a "retrying" network element in case of a network error than not being aware of where the error comes from. Just imagine a loop or a beaten bandwidth limit. A UDP-syslog message maybe never arrives while a tcp-syslog message is retried to be sent. We have multiple log servers and want to move to tcp with at least 2 of them.
    – flo
    Commented Mar 14, 2018 at 15:41

2 Answers 2

Reset to default
3

As far as I could see, there is no Cisco document that describes what happens in the scenario that you mention.

But even if there was such a document, you would be best advised to verify the behaviour for yourself, with your device and software version, because syslog is such an important component.

Here is how I would verify it:

  1. Configure and verify the basic functionality
  2. Configure "logging buffered 4096" (the default)
  3. Write an EEM applet to emit a syslog message every second. Make the text somewhat long (say more than 256 characters), just to check for truncated syslogs.
  4. Start the applet and verify that the syslog host is receiving the logs
  5. Now disconnect the syslog host (by physically unplugging the ethernet cable from the host machine). Don't shutdown the host or do anything that might cause the TCP session to be FIN'd. You might also want to verify that the management interface on the 3560 (where you are presumably sending the syslogs from) stays up.
  6. Wait for long enough to fill the 4096-byte logging buffer. If you are logging 256 bytes every 1 second, that would be a 16 second wait. Wait for a few more seconds just to be sure.
  7. Now reconnect the syslog host
  8. See if the syslogging resumes at all, or whether some manual intervention is needed on the 3560 side to make sure the syslogging resumes
  9. Now check for what happened to the logs that were transmitted during the 16 second window. Use the timestamps to check which, if any, messages were dropped.

In an enterprise network, packet drops in the management network are less likely than a complete outage of the syslog server, so the test procedure above is a simulation of a real-life use case.

Improve this answer
4

Syslog streaming is independent of the router resources since it sends configured logs to an external Syslog server. Losing the syslog would mean that these logs go back to the internal buffer.

The internal buffer is allocated a piece of memory by the OS itself, but is user-configurable with values ranging from 4096 to approx 2 billion. However, setting a larger value for a buffer means that you are eating up into that precious memory which could be needed for other router tasks.

So, if you set the internal buffer value to a value that you feel would not starve others ( this could vary depending on where the router is placed in the network) and you lose the syslog server, you should do fine. The only thing you would lose are the logs since internal buffer is similar to a circular queue which means newer messages replace older ones.

NOTE : We have 4 syslog servers in our network, and I think that gives us a good amount of HA

Improve this answer
1
  • The messages go the internal circular buffer displayed with "show logging". That buffer is then played out to the syslog servers. That gives some allowance for unavailable syslog servers. If the TCP connection times out then only messages submitted to the log after the connection reestablishment are logged, not the entire circular buffer (ie, logging into the router and saying "show logging" can reveal more of a network fault than may be on the syslog servers).
    – vk5tu
    Commented Mar 15, 2018 at 23:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.