logging buffered 65530 informational
This command enables system logging so that syslog events that are triggered are saved within the local buffer to be viewed at a later time. The specific command indicates that the buffer size in bytes is 65530, and that the type of syslog messages that are buffered are of a severity level of “informational” and lower. Note that there are eight severity levels:
When you set the severity level to informational, all syslog messages are buffered except for debugging.
logging trap informational
This command involves syslog messages that are sent to external syslog servers. A trap is an unsolicited (meaning, not requested) message that is sent to a remote network management host. This command indicates the severity level of syslog messages that should be sent to the remote host. Regardless of what this command is set to, in order for it to have meaning, the logging host command must also be applied which configures the remote host to which syslog messages will be sent.
no logging console no logging monitor
These commands disable the appearance of syslog messages on the console (connected directly via the serial cable) or on the monitor (remote connection using either telnet or SSH). These commands should be implemented so that when you connect to the CLI, you will not be distracted by messages appearing on the CLI while trying to configure the device. You must enable these commands if you want to view debugging information live as the events occur in real time.
enable secret var123
This command configures the password you must type when you want to enter into global configuration mode.
You can find more information about logging commands at the following Cisco documentation.
There are several free syslog servers available online. If you do a search for “free syslog server” you should find several good options for both Windows and Linux operating systems. In this lesson, Rene recommends Adiscon LogAnalyzer which is free. For step by step instructions on how to setup a syslog server, take a look at the documentation available for the server of your choice. For configuration of the Cisco device to send syslog messages to a server, take a look at the following lesson.
I have a question: On Packet Tracer I SSH’d from one switch to another, disabled terminal monitor, however I was still seeing messages show up when a did something like shutdown an interface, as per the below:
SwitchB#terminal no monitor
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line. End with CNTL/Z.
%LINK-5-CHANGED: Interface FastEthernet0/7, changed state to down
Is this just because Packet Tracer doesn’t quite behave like “real” Cisco devices? On a real device would I expect to not see these messages if terminal monitor was disabled?
I tried going into packet tracer and I issued the term no mon command on a 2901 router. I found that when I shutdown an interface, no message appeared. I tried the same with a 2960 switch and it seems to be working. I’m using Packet Tracer 7.0.0.0306.
That’s interesting behaviour. Can you tell us what version you’re using?
If we enter more than one syslog server for our device to send its syslog messages to how does it handle it? In other words does it use the first as the primary and failover to the second if the first is unavailable or does it send to both simultaneously or does it alternate, or some other such thing?
I have a requirement to configure syslog resilience for all our Cisco devices so is it as simple as entering more than one logging host or do we need some other mechanism? Can it be done by means of ip sla for example? If so how would we do it?
Actually, it is as simple as configuring more than one logging host. When you do this, syslogs are sent to both servers simultaneously. You can find out more information about best practices for deploying syslog in a high-availability and scalable fashion for Cisco networks here:
SNMP and Syslog are similar in that they are both used to monitor network devices. But the similarities end there.
Syslog will generate a message whenever an event occurs on the device. The level of detail and what events are actually logged depends upon the configured severity level. There are eight severity levels from debugging, which is the least severe, denoted by 0, and Emergency which is the most severe denoted by 7. You can set the level which you want to log messages. A level of 4 for example, will log all Syslog messages with a severity level of 4 and above. Logging can take place on the device itself, or logs can be sent to an external Syslog server to be further parsed and analyzed. More about Syslog can be found here:
SNMP on the other hand is somewhat more active. SNMP uses what are known as traps. A trap is a notification that is sent as soon as an event occurs. Traps can be configured to be sent as soon as an event occurs, or an SNMP server can request particular traps, that is, the status of those elements in the device, at any particular time. SNMP v3 also includes acknowledgements to these traps, so such communication becomes reliable, something that is not available with Syslog.
SNMP is also able to send commands from the SNMP server to the device to change configuration parameters, something that syslog does not do. You can find out more about SNMP at the following lesson:
You can also learn about the various SNMP versions that add additional capabilities to the protocol.
The show logging command will show you all of the logs that have been saved on the device. The number of events it will keep in the logging buffer depends upon the size of the buffer. The default buffer size on most systems is 4096 bytes, but you can change the size of the buffer using the logging buffered command.
The output will appear on the screen and can show you all of the contents of the buffer. You can’t choose only the last lines to be displayed, however, you can output the results of a show command to a text file using the following command:
Is there any specific advised/recommended amount of percentage of Ram that we should use for logging buffered ?
If logging buffered was set too high and the switch/ router needed the extra ram would the switch overwrite the logs files and take the ram or simply the switch would just be out of ram ?
According to Cisco’s documentation, it seems that there is a danger of the available RAM on a device being depleted if the logging buffered command is set too high. Specifically, it states:
When you resize the logging buffer, the existing buffer is freed and a new buffer is allocated. To prevent the router from running out of memory, do not make the buffer size too large. You can use the show memory EXEC command to view the free processor memory on the router; however, the memory value shown is the maximum available and should not be approached. The default logging buffered command resets the buffer size to the default for the platform.
The command does give you a maximum buffer size of 2147483647 in bytes, which is over 2 Gigabytes in size. If this is greater than the physical memory available, then you can indeed run out of memory if this is set too high.
The recommendation is to keep the size as small as possible. Use the commands above to determine the amount of available RAM, however, if you are approaching the limit of the device and you need considerably more logging history, then use an external Syslog server.
The Syslog feature is very useful for monitoring a large network and troubleshooting. I have several large networks that I oversee and I have configured a Syslog server for each network to collect the Syslog messages that are generated by the network equipment.
Looking at individual syslog messages can be useful, but sometimes you may have hundreds or thousands of messages that you have to sort through, and that is not useful at all! That is where you can use a Syslog server to not only collect the logs, but also to analyze them, generate reports, and alerts, and provide you with useful and visual information about the current and historical state of your network.
LibreNMS is an example of a network monitoring tool that includes Syslog management.
When it comes to logging to the VTY lines, both logging monitor level and terminal monitor must be issued, correct?
Why does it work like this? Isn’t issuing them both a little redundant? Why issue the terminal monitor command if we’ve already enabled logging to the VTY lines using the logging monitor level command?
While it might seem redundant, the two commands actually serve different purposes in Cisco IOS.
The command logging monitor level is used to set the severity level of messages that will be logged to the terminal lines (VTY). The level parameter specifies the types of messages to be logged. For instance, if you set the level as ‘debugging’, it will include lower severity level messages such as informational, notifications, warnings, errors, critical, alerts, and emergencies.
On the other hand, the terminal monitor command is used to enable or disable the display of logging messages to your current VTY session. By default, logging to the terminal lines is disabled. So, even if you’ve set a certain severity level with the ‘logging monitor’ command, even though those messages will be logged, you won’t see the messages on your CLI until you enable them with ‘terminal monitor’.