In my previous article, I explained what syslog is and why it’s used. In this article, I’m digging into how to configure syslog on network devices.

The explanations and examples will be a bit Cisco specific, mainly because that’s the gear I’m most familiar with. Essentially every modern network device has at least some syslog capabilities, though. The ones that don’t support it directly have their own logging consoles that can usually be configured to filter and forward logs on to another centralized syslog server.

Enabling logging on a Cisco device

In its most basic form, the syslog protocol sends text messages over UDP port 514. You can enable basic logging on most Cisco devices using the command “logging IP.” In my network, the syslog server’s IP address is 192.168.2.47, so I would type this:

!
 logging 192.168.2.47
 logging on
!

In fact, the “logging on” (“logging enable” on some devices) isn’t usually necessary. This command just turns on the logging function. I included it here in case it had previously been disabled.

By default, Cisco devices use a syslog facility code of “local7” for all of their messages. As I explained in the previous article, facility codes are just a way of separating messages from different types of devices and from different services. Otherwise you can find yourself completely inundated with messages and unable to use them effectively.

Read more: Network engineer Kevin Dooley explains syslog severity and facility codes and how they work.

Using syslogd on a Linux system

My syslog server is a Linux system, and I’m just using the default “syslogd” program that comes with Linux. Since I want log messages from my Cisco devices to be sorted separately from the messages created by the Linux system itself, I’ve modified the server’s syslog configuration a bit by adding the following line to the /etc/syslog.conf file:

#
local7.*		/var/log/cisco.log
#

This tells the syslogd daemon that, whenever it sees a log message with the facility code set to “local7,” it should put it in the specified file no matter the priority level. Note that if you do this, you’ll need to make sure to create this file with appropriate permissions so the syslogd program can write to it.

In that configuration command, you’ll see a “*” which is a wildcard that matches messages of any priority. So you can further sort your messages so that any debug messages are sent to one file, informational messages to a second file, and everything else to a third file:

#
local7.notice		/var/log/cisco-notice.log
local7.info		/var/log/cisco-info.log
local7.debug		/var/log/cisco-debug.log
#

By default, the standard syslog.conf rule will match a specified priority and anything higher. So the first rule matches “notifications,” which are priority 5 as well as priorities 0 to 4. The second rule then matches “informational” messages, which are priority 6. And the third line matches “debug” messages, which are priority 7.

Changing the default logging levels on a Cisco device

But suppose I didn’t want to use those default values. The first thing I’d want to do is send messages with different priority values to my server.

In the previous example, my Cisco device was just configured with the default logging level, which is “informational.” This means the device will send all messages to the server that are of level 6 or “higher” (in this case, higher priority means a lower numerical value).

If I want to see debugging messages as well as all of the higher priority messages, I can use this command:

!
 logging trap debugging
!

Similarly, if I only want to see warning messages (priority 4) or higher, I can use this command:

!
 logging trap warning
!

I don’t generally recommend configuring the logging priority level much higher than this. You’ll almost never see priority 0 or 1 messages because they usually indicate a catastrophic failure. And in my experience, the designations of priority 2, 3, and 4 messages are largely arbitrary. I usually just leave the default value of 6, or “informational.”

One thing you sometimes need to do is change the UDP port number:

!
 logging trap 192.168.2.47 transport udp port 8514
!

This command says, for this server, we want to send to UDP port 8514 instead of the default port 514. This only applies to the specified server. You may have multiple servers configured, and the device will send each message to all of the configured servers.

You can also configure the device to use TCP instead of UDP.

!
 logging trap 192.168.2.47 transport tcp port 8514
!

Note that, by default, the TCP port number is 601 on many Cisco devices. But there are a lot of TCP syslog implementations that use port 514. You need to verify which port your server is expecting to use.

Network devices often have several interfaces, and each of those interfaces could have a different IP address. You can easily have a situation where the device sends a “link down” event with one IP address and the corresponding “link up” event with a different IP address. It can be confusing to search the log files for these two messages. For this reason, it’s useful to specify a particular source address or source interface for syslog messages:

!
interface loopback0
 ip address 192.168.10.1 255.255.255.255
 no shutdown
!
logging source-interface loopback0
!

In this case I’ve specified a loopback interface as the source. I did this because whichever physical interface I choose might be down when the device needs to send a message. If you do this, you’ll need to make sure to create the loopback interface like I’ve done in the example.

Securing syslog messages on a Cisco device

One of the drawbacks to using syslog is that the messages—which could be sensitive in nature—are sent in clear text and can be readily intercepted or forged. In practice, I haven’t heard of any such attacks actually happening because most IT pros are careful to keep their syslog traffic confined to trusted network segments. But it’s possible.

Syslog can be, at least in theory, secured using SSL encryption. This requires using certificates on both the network device and the server to mutually authenticate one another. I say “in theory” because not all Cisco devices support this feature. Starting in version 9.2.1, Cisco Nexus switches support syslog and ASA firewalls also support SSL syslog, but it doesn’t appear to be supported in other Cisco product lines.

Read more: Kevin Dooley explains how to migrate a Cisco ASA firewall configuration from old syntax to new.

This feature isn’t used in most network installations because of the administrative overhead of keeping the certificates updated, and because it consumes more system resources to maintain the encrypted sessions. It’s much easier for a server to support logging from large numbers of remote devices over UDP, where the only overhead is in receiving individual packets and dropping them in the appropriate file or database table. There’s no session to maintain and no certificate to validate.

For these reasons, I generally don’t recommend using the encryption features of syslog. Instead, I prefer to design the network so these messages and other management traffic is isolated away from users and other production traffic.