Syslog

System Message Logging (Syslog)

Introduction to Syslog

A fundamental part of any network engineer's toolbox is syslog. It is not only the tool to collect the logs but also knowing what the network is saying in real time, respectively. Syslog is a standardised protocol used to send system messages between the devices in the network. Think about it like a black box for your router/switch. It captures all relevant information and events happening on the network, providing valuable insights and troubleshooting capabilities.

Cisco IOS notifies users (network engineers) about the event on the device's command-line interface (CLI). This is a default setting of each router and switch. Users can customise these notifications to fit their specific needs and preferences, and I will write about it in the next paragraphs.

Given that there is not any action needed to activate logs on a Cisco router/switch when you first switch it on. The logs will automatically begin activating. Please note that this process may vary depending on the specific model and software version. But in most cases you do not need anything.

Nonetheless, if you need to ensure that logging system messages is activated, use the command below:

Figure 1 – Syslog settings for console and remote users

(config)# logging console

In a situation when you need to log in remotely, the "logging monitor" command must be applied from the global configuration mode. It allows the IOS to send messages to all users logged in remotely. Again, this is a default configuration for remote users, but one more step must be done to enable remote users to see log messages.

Each user must enter the command "terminal monitor" in their local configuration mode in order to see log messages generated on the IOS device.

# terminal monitor

Once a message has been sent to the command line, ISO has two options for saving the logs. First, the device's RAM can be used to store messages. The logging buffered global configuration command must be used for this setup. Sending logs to the local server (syslog server) is the second technique. For the second technique we should use the command: logging host {address | hostname}.

(config)# logging buffered

(config)# logging host 192.168.20.201

A typical syslog message on a Cisco device looks like the one below:

Apr 12 12:34:56: %LINK-3-UPDOWN: Interface FastEthernet0/1 changed state to up.

Figure 2 – A typical syslog message on a Cisco router and switch.

Let’s break it down:

Apr 12 12:34:56: Timestamp
%LINK: Facility (module or feature reporting it)
3: Severity level (more on this below)
UPDOWN: Mnemonic (type of event)
Message body: “Interface FastEthernet0/1, changed state to up”

We can change the timestamp to a sequential number by applying the commands 'no service timestamp and service sequence numbers.

(config)# no service timestamps

(config)# service sequence-numbers

Severity Levels

Imagine this scenario. You have about 100 routers and switches, and every single debug message is spamming your log server 24/7. This is total chaos. This is where the severity comes into place.

To make it make more sense, let's break down the eight severity levels one by one in the table below. The two top levels create the severe category. Messages from these levels (0, 1) are very serious and must be reacted to immediately.

Levels 2, 3, and 4 make up the next level, which is impactful. These logs inform about critical system conditions. Continuing down, levels 5 and 6 are messages from important notes to normal. Last, level 7 is about debugging.

Table 1 – Log message severity levels

Configure Logging Message levels for Logs Service

We are able to configure for each service level, like console, monitor, buffer and server, with specific setting levels of the log severity.

(config)# loging console {level name} {level number}

(config)# loging monitor {level name} {level number}

(config)# loging buffered {level name} {level number}

(config)# loging host {IP Address} {level name} {level number}

The configuration is simple; we need to specify the level name or level number to select the service from the general configuration mode.

This allows for easy customisation of logging settings based on the specific needs of each service. By specifying the severity level, engineers can ensure that logs are appropriately filtered and stored for efficient troubleshooting.

To conclude, the command "show logging" is employed to inspect the current logging configuration and confirm that the modifications have been effectively implemented. Additionally, it is important to bear in mind that debug commands can be executed from the execution level (exec) of the terminal. This approach is particularly useful for resolving specific issues in real time. Debugging commands, however, should be used carefully because they can produce a lot of log data and possibly affect system performance.

Log Message in Lab

Let's see how syslog messages work in practice. I set up a modest lab with two routers and two switches that exchange messages between devices.

Router 1 has been configured with varying levels of services, including the logging console, remote logon, buffering files, and logging server. I established a specific level of severity for each of these services. For instance, when a user logs in directly via a console connection, his screen will display the lower level of message severity (level 7), which is debugging. The same level was established for the user who is remotely connected to the router (second line on the script). The RAM memory system is the place where messages for levels 4 and above will be stored. It is defined by a simple command by the third line of this script. The IP address of the host server was set up at 192.168.20.105, and all records are transmitted directly to this location on the private network.

Figure 3 – Network topology.

R1(config)#logging console 7

R1(config)#logging monitor debug

R1(config)#logging buffered 4

R1(config)#logging host 192.168.20.105

*Apr 13 00:19:23.414: %SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 192.168.20.105 port 514 started - CLI initiated

The same configuration I applied to router 2. The last command in the below script shows the minimum severity level of logs that router 2 will send to a remote syslog server. It means that only log severity from 0 to 4 levels will be sent to the remote syslog server, and messages from levels 5, 6 and 7 will be ignored.

R2(config)#logging console 7

R2(config)#logging monitor debugging

R2(config)#logging buffered 4

R2(config)#logging host 192.168.20.105

R2(config)#logging trap warning

Similar settings I did for the switch 1 and switch 2, which are shown in the scripts below.

Sw-1(config)#logging console 5

Sw-1(config)#logging monitor debugging

Sw-1(config)#logging buffered notifications

Sw-1(config)#logging host 192.168.20.105

Sw-2(config)#logging console 5

Sw-2(config)#logging monitor debugging

Sw-2(config)#logging buffered 3

Sw-2(config)#logging host 192.168.20.105

Figure 4 – Linux server syslog with shown messages from router 1 and router 2.

Summary

Syslog is a crucial tool for network engineers, providing real-time information and troubleshooting capabilities. It is a standardised protocol used to send system messages between devices in the network, serving as a black box for routers and switches. Cisco IOS notifies users about events on the device's command-line interface (CLI), which can be customised to fit specific needs.

Logging system messages are activated automatically when a router/switch is switched on, but activation may vary depending on the specific model and software version. To enable remote users to see log messages, each user must enter the command "terminal monitor" in their local configuration mode. ISO has two options for saving logs: using the device's RAM to store messages or sending logs to the local server (syslog server).

Severity levels are used to categorise log messages into eight levels: emergency (0), alert (1), critical (2), error (3), warning (4), notification (5), informational (6), and debug (7). Configuring logging message levels for each service level allows for easy customisation of logging settings based on the specific needs of each service.

Page updated

Google Sites

Report abuse