How to configure logging on Cisco IOS

Overview

Device logs often offer valuable information when troubleshooting a network issue. Interface status, security alerts, environmental conditions, CPU process hog, and many other events on the router or switch can be captured and analyzed later by studying the logs. By default, all log messages on a Cisco router or switch are sent to the console port. Only users that are physically connected to the console port may view these messages. If you are connected to a Cisco device via Telnet or SSH and want to see console messages, you can enter the command terminal monitor in privileged exec mode. Cisco devices support five types of logging:

console logging – all messages are sent to the console port (default)

terminal logging – similar with the console logging but the messages are displayed on the VTY lines of the device.

buffered logging – stores the log messages using a circular buffer in the device’s RAM

Cisco logging severity levels and log format

Each Cisco log messages has a severity level assigned to it, along with a description indicating the seriousness of the problem or event. Severity levels range from 0 (the highest) to 7 (the lowest).The next table lists these levels from highest to lowest importance.

Level

Level keyword

Description

Syslog Description

0

Emergencies

System unusable

LOG_EMERG

1

Alerts

Immediate action needed

LOG_ALERT

2

Critical

Critical conditions

LOG_CRIT

3

Errors

Error conditions

LOG_ERR

4

Warnings

Warning conditions

LOG_WARNING

5

Notifications

Normal but significant condition

LOG_NOTICE

6

Informational

Informational messages only

LOG_INFO

7

Debugging

Appears during debugging only

LOG_DEBUG

Log messages with severity levels of Alert or Emergency are rarely seen because this means that the router is inoperable. The log message format on a Cisco IOS device has the following syntax:

timestamp: %<facility>-<severity>-<mnemonic>: <message_text>

These fields have the following meanings:

timestamp – indicates the date and time of the message or event. The format of the timestamp can be mm/dd hh:mm:ss or hh:mm:ss (short uptime) or d h (long uptime).

facility – indicates the facility to which the message refers (for example, SNMP, SYS, and so forth).

severity – represents the severity level of the message indicated in the above table. It uses one single-digit code from 0 to 7.

Below is displayed a real example from a Cisco router which follows the above pattern.

Mar 1 00:05:16.819: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up

From the above line we can see that the message is split into three sections separated by colons. The first section is optional and represents the timestamp (Mar 1 00:05:16.819). The second section contains the message code and severity level. Here ‘%LINK’ is the facility followed by the severity ‘3’ and the mnemonic ‘UPDOWN’. The last section of a log is a human readable description of the message.

Enabling logging

As mentioned previously by default logging is enabled only for the console port. To enable logging to all supported destinations other than the console, enter the following global configuration command:

R1(config)# logging on

Using the logging on command, you enable any other configured destination for logging, such as a syslog server or the router’s internal buffer, for logging. This command must be enabled before you can log system messages to locations other than the console port. You can control individually which processes will receive logging messages with other logging commands.

When working at the console or remotely on a vty line log messages can pop up right in the middle of typing a command. This behaviour can be very annoying. This message has no bearing on the command that you are typing, and you can continue typing to complete your command. To resolve this issue we must configure synchronous logging on the console or the vty lines.

R1(config)# line type #
R1(config-line)# logging synchronous

The line type specifies the console or the vty line followed by the line number (#). When it’s enabled, synchronous logging instructs Cisco IOS to display the original prompt with the information that you have already typed on the command line. This command support some additional parameters like level to specify the severity level and limit which specifies the how many synchronous messages should be queued up before the router starts dropping new messages. The default values for the severity level is 2 and for the limit is 20 messages.

The logging console command refers to logging to physical TTYs, such as the console and auxiliary lines and the logging monitor command refers to logging to logical VTYs, such as Telnet/SSH sessions. The severity level can be specified using the values from the second column of the above table. The default severity level for the logging monitor command is set to 7 (debug).

If you want to use these two commands, you still must enable logging with the logging on command. For example, to log only messages on the VTY lines with a severity level of “warning” we need to run the following command in global configuration mode:

R1(config)# logging monitor warnings

Internal buffer logging

Logging messages to TTYs or VTYs is not always a good solution because the message can scroll past the screen and out of your terminal software’s history buffer. In our case the issue can be resolved by logging the messages to the router’s internal buffer. To set up logging to the router’s buffer, use the following command:

R1(config)# logging buffered [buffer_size | severity_level]

The buffer_size parameter is optional and indicates the size of the buffer which can range from 4096 bytes to 2,147,483,647 bytes. The severity_level parameter which is also optional refers to the severity level of messages and can use any value specified on the second column of the above table. After the buffer fills to capacity, older entries will be deleted to make room for newer entries.

For example, to increase the default buffer size (4096 bytes) to 1 Mbyte use the following command:

R1(config)# logging buffered 1024576

Note: Caution should be taken if increasing the buffer size to a very large value because this can cause the router to run out of memory.

Enabling Error Log Counting

Newer versions of Cisco IOS beginning with 12.2(8)T introduced a new feature called Error Log Count. This feature allows us to keep track of the number of occurrences of a particular log message, as well as the last occurrence of the message. To enable this feature use the following command in global configuration mode:

R1(config)# logging count

Enabling timestamps for log messages

By default, log messages do not record any date and timestamp information. Adding a timestamp to log messages is very useful when we want to review later the exact time when the event occurred. In order to enable timestamps on log messages use the following global configuration command:

R1(config)# service timestamps log {uptime | datetime}

The uptime keyword specifies that timestamps should be based on the system uptime (for example – 1w2d means uptime for 1 week and 2 days). Using the datetime keyword specifies the current date and time in UTC format when the message was logged. When using the datetime keyword we can set some addtional parameters.

The msec parameter specifies that the date/time format should include milliseconds. Using the localtime parameter we can display the timestamps based on the time zone configured locally on the router. Additionally we can include the time zone in the display using the show-timezone parameter. As a practical example let’s enable the timestamps using our localtime and timezone parameters.

R1(config)# service timestamps log datetime localtime show-timezone

After running this command and then checking the logs we see in the below output that the timestamps was enabled and the time-zone was displayed (EET in my case meaning Eastern European Time).

From the above output we can observe that syslog is enabled but not configured, the log buffer is enabled with a severity level of debug and has a size of 64Kbytes. Additionally we can see that timestamps for the log messages is disabled. Another useful parameter for the show logging command is “count” which allow us to see the error count if the logging count feature was enabled.

The above example shows the number of times each event have occurred and the most recent time that each error message occurred. System error messages are grouped into logical units called “Facilities” based on Cisco IOS software components.

To clear the log messages from the internal buffer, use the clear logging command:

R1# clear logging

When running this command a confirmation message will ask if you really want to clear the internal buffer log. Press ‘y’ to clear it or ‘n’ to skip.

Rate limiting log messages

By default, a router will display all log messages to the console as they are created, regardless of how many there are. Beginning with IOS Version 12.1(3)T Cisco introduced a new feature called rate-limiting which will throttle the number of packets by limiting the rate of messages logged per second. You can use this feature to avoid a flood of output messages. To enable it use the following command in global configuration mode:

R1(config)# logging rate-limit [number | except severity]

The valid values for ‘number’ range from 1 to 10000 and the default is 10. Also we can specify a severity as a numeric value from 0 to 7 by appending it to the except keyword. This will exclude messages of this severity level and lower. For example if we want to rate-limit messages with a severity level of warnings and higher by 20 per second type the following command in global configuration mode:

R1(config)# logging rate-limit 30 except 4

Disabling logging

If you want to disable any kind of logging use the place the ‘no’ keyword before any logging global or line configuration command. So for example to disable logging for the router internal’s buffer use the following command:

R1(config)#no logging buffered

Conclusion

Logging to console, vty lines or internal buffer has some limitations like the storage capacity offered by the device and the fact that all logs are lost upon device reboot. If you manage a large number of Cisco devices a better approach will be to centralize all logs to an external Syslog Server.