Going beyond the question of what is sylog and why it’s used, this article digs into how to configure syslog on network devices.
The explanations and examples will be a bit Cisco IOS specific, mainly because that’s the gear I’m most familiar with. Essentially every modern network device has at least some syslog capabilities. 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 a centralized syslog server.
Here are the basic steps I tend to follow for Cisco syslog configuration, to keep the messages manageable, and the network overhead low.
Before configuring a Cisco device to send syslog messages, make sure that it is configured with the right date, time, and time zone. Syslog data would be useless for troubleshooting if it shows the wrong date and time.
Step 1: Enable logging on the Cisco device
The syslog protocol sends clear text messages over UDP port 514. You can enable basic logging on most Cisco devices using the command “logging IP.” On 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 !
Note: “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.
Step 2: Modify the syslog config for facility codes
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 services. Otherwise, you can find yourself completely inundated with messages and unable to use them effectively.
If you’re only logging from one service to a remote syslog server (one service code is the default with Cisco devices), then you typically don’t need to change the facility. If for some reason you do, it’s an easy change. Simply type the following, replacing ‘X’ with a number 0-7:
logging facility localX
Quick tip: if you’re using network management software like Auvik, all your configurations, current and new, will be part of your network configuration backup for quick retrieval if any of your server tweaks don’t perform the way you want them too!
Step 3: Change the default logging levels
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).
Suppose I didn’t want to use those default values, and I only want to send messages of a certain priority or higher. If I want to see debugging messages as well as all 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.” The priority you use may also depend on your network performance monitoring tool, and its storage capacity and log ingestion limits.
Step 4: Define destination port and IP address
One thing you may want to do is change the UDP port number, or use TCP ports instead. To change your UDP port, use the following transport command:
! logging trap 192.168.2.47 transport udp port 8514 !
This command says, “For this server, I want to send messages 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 the configured servers.
To configure the device to use TCP instead of UDP, use this command:
! 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.
Step 5: Define source IP address
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 syslog message for 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. Loopback interfaces can never go down, so they are a convenient way to uniquely specify a device. If you do this, you’ll need to make sure to create the loopback interface like I’ve done in the example.
Step 6: Securing syslog messages on a Cisco device (Optional)
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 encrypted syslog, and ASA firewalls also support SSL syslog, but (at the time of writing this) 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. After all, network segmentation is good network management.
Appendix: Cisco syslog commands quick reference guide
|Router# configure terminal
|Enters global configuration mode.
|Router(config)# service timestamps type datetime [msec] [localtime] [show-timezone]
|Timestamp syslog messages; the options for the type keyword are debug and log.
|Specifies the syslog server by IP address or host name; you can specify multiple servers.
|Router(config)# logging trap level
|Specifies the kind of messages, by severity level, to be sent to the syslog server. The default is informational and lower.
Use the debug level with caution, because it can generate a large amount of syslog traffic in a busy network.
|Router(config)# logging facility facility-type
|Specifies the facility level used by the syslog messages; the default is local7.
Possible values are local0, local1, local2, local3, local4, local5, local6, and local7.
|Returns to privileged EXEC mode.
|Router# show logging
|Displays logging configuration.
For more information, please read the original Cisco documentation on Configuring Cisco Devices to Use a Syslog Server
Your Guide to Selling Managed Network Services
Get templates for network assessment reports, presentations, pricing & more—designed just for MSPs.
Thanks for the detailed steps you provide. How about configuration for the successful and failed logins? Specially for routers and switches.