In this tutorial we are going to explore four different tools available on your Cisco router’s IOS that allow you to manage it. This list of tools is not exhaustive and various other tools might fit as well under the “System Management” category.


Logging is an important feature of any advanced system because it allows users, administrators, and troubleshooters to find out what is happening or has happened on a system. Logs may signal success, failure, syntactical error, etc., and they do help an operator know the results of his/her interaction with the system.

As a security feature, logs are a capital source of information for security managers when monitoring systems to make sure they are used and operated as intended. They are also the last resort to auditors and forensic staff when trying to find out breaches and security incidents.

On a Cisco router with IOS, logging is turned on with the “logging on” command:

Log destinations

The next parameter that we can configure on our logging system is the destination of logging messages that the system produces. The system can be set to send the logs to the following destinations:

  • Console: for the user logged in via the console.
  • Monitor: for the user logged in through SSH or telnet.
  • Memory buffer: both console and remote users can view these logs by reading the memory buffer with the “show log” command.
  • SNMP trap: in this case the system logs are sent to a dedicated syslog server. This option is beyond the scope of our article and configuring a dedicated syslog server will not be covered in this tutorial.

The memory buffer (when configured) can be viewed with the command show log to see the most recent events and logs, and therefore might not contain older logs based on the size of the buffer. The console and monitor options are useful in case of limited logging. When there are plenty of errors logged the messages may scroll too fast for comfortable reading. This makes a dedicated syslog server the best option for always available logs.

The syslog messages are grouped in severity levels (0 through 7) with 0 being the most severe. Moreover, for every destination seen above the level of loggings can be set. The eight severity levels can be seen below. Severity levels are inclusive with severity 4 encompassing level 0 through 4.

As an example, let’s set the router to log severity level 5 to the memory buffer and severity level 0 to console. This means level 1, 2, 3, 4 and 5 messages will not show up on the console but can still be found in the memory buffer.

If we go to the interface FastEthernet 0/0 and issue a shutdown command, no log message will appear at the console, but if we check the memory buffer the log messages are seen reporting an interface shutdown at 01:52:58.479.

The interface shutdown has generated a severity 5 log in the memory buffer.

If we want to see the same log in the console area, let’s increase the severity level to 5 on the logging console command telling the syslog engine to now send log messages from severity 0 up to severity 5 to the console.

The log message shows up on the console:

It also shows up in the log buffer:

The memory buffer can soon become too small for the amount of logging we want to keep retrievable, calling for an increase in size.

To increase the buffer size:

Note that increasing the buffer size will flush out the previous buffer content.

The amount of memory buffer to dedicate to syslog is a function of the amount of memory available on the router and the amount of the logs we want to keep available in the memory buffer at any one particular moment in time.

Logs augmented with sequence numbers

Another available feature with syslog is logs with sequence numbers. This feature is actually useful for navigating and sorting out the logs so that in case of someone deleting or tampering with the logs repository like the syslog server, you can detect it by the gap(s) in the sequence numbers.

To put sequence numbers on your router generated logs we use the service sequence-numbers command:

Now the logs will start appearing with sequence numbers:

Logs with timestamps

Log timestamps can be in uptime or localtime format, where the uptime format shows the time since last reload and the localtime format shows the actual local time on the system. The system’s local time is either provided by an NTP server or manually set.

If we set the debug and log timestamps to be written in uptime, we see that the logs in the memory buffer are timestamped 00:15:52, 00:16:11 and 00:17:46. That is because our router was started 17 minutes ago. The show clock command still shows the system’s real local time.

If we chose to timestamp our logs with the datetime value,

the new logs would be time stamped accordingly with date, local time (including milliseconds), time zone and year.

II. Telnet vs. SSH

It is rare in real life situations to have access to the router’s console. Wide Area Networks can sport a big number of routers and switches and span entire regions requiring administrators to setup remote connectivity to their remote devices. The most used remote connectivity tools are telnet and SSH, each one with its own benefits.

To set up a remote connectivity facility on a Cisco router, you configure virtual terminal (VTY) lines. The number of virtual lines configured equals the number of simultaneous remote connections available on that router. The default is five VTY lines.

To configure ten VTY lines:

We set VTY lines from 0 to 9:

Once in the line vty configuration prompt, we can choose whether to configure telnet or SSH or both on the router device.

A variety of other remote connection methods are available here but we will focus on the two most used for brevity’s sake.

a. Telnet for remote access

Telnet is the default method for remote access to a Cisco router. The main inconvenient feature of telnet is that all the traffic is sent in clear text (unencrypted). This is can be a deterrent to remote connections through public networks like the Internet.

Access lists can be used to be selective about who can telnet into our router. Custom ports can also be configured so that remote users need to know what port the service is running on.

To specify what protocol we want to use for remote access, we issue the transport input command.

Once telnet is enabled on these VTYs, we go on and enable local password checking for remote connection users.

This will allow the system to authenticate users against its local database. Authentication against a TACACS+ server is beyond the scope of this tutorial.

Here we test telnet:

SSH, telnet and other remote connectivity methods are not mutually exclusive. They can be set side by side for a variety of remote connectivity options. In our example we will end up with telnet and SSH enabled on the same router, though telnet is not recommended for its lack of security.

b. SSH for remote access

SSH allows encryption of the authentication and the actual payload of the packet. Therefore, packets travel encrypted, protecting passwords and actual payloads against sniffing. SSH is off by default and like telnet it uses either login local or AAA (RADIUS/TACACS+).

Let’s add SSH to telnet transport input method.

To enable SSH we will need to first generate the RSA keys necessary for the operations of SSH.

The router complains about the domain name not being set because the domain name is used in the RSA keys generation.

We set the domain name first:

And then we generate the keys:

We don’t need to configure the local authentication since it was set during telnet setup. This means the same local database will authenticate both the telnet and SSH users.

By default the SSH client on the Cisco router uses version 1 of SSH. If we want to use version 2 for better encryption, we specify it on the command.


The IOS in Cisco routers allows the administrator to set up texts to be displayed before login prompt and even after the successful login of a remote connection user.

Common banners used are:

The MOTD or Message Of The Day: The MOTD appears on the screen before the login prompt.

Login: The Login Banner will appear between the MOTD Banner and the Login prompt.

The Exec Banner will appear after the login and password prompt once the exec is invoked.

And the results are shown below:

That’s it for this tutorial. We hope it was helpful for your understanding of the covered topics.