Cisco Network Time Protocol (NTP)

NTP (Network Time Protocol) is used to allow network devices to synchronize their clocks with a central
source clock. For network devices like routers, switches or firewalls this is very important because we
want to make sure that logging information and timestamps have the accurate time and date. If you
ever have network issues or get hacked, you want to make sure you know exactly what and when it
happened.

Normally a router or switch will run in NTP client mode which means that it will adjust its clock based on
the time of a NTP server. Basically the NTP protocol describes the algorithm that the NTP clients use to
synchronize their clocks with the NTP server and the packets that are used between them.

A good example of a NTP server is ntp.pool.org. This is a cluster of NTP servers that many servers and
network devices use to synchronize their clocks.

NTP uses a concept called “stratum” that defines how many NTP hops away a device is from an
authorative time source. For example, a device with stratum 1 is a very accurate device and might have
an atomic clock attached to it. Another NTP server that is using this stratum 1 server to sync its own time
would be a stratum 2 device because it’s one NTP hop further away from the source. When you
configure multiple NTP servers, the client will prefer the NTP server with the lowest stratum value.

Cisco routers and switches can use 3 different NTP modes:

 NTP client mode.

 NTP server mode.
 NTP symmetric active mode.

The symmetric active mode is used between NTP devices to synchronize with each other, it’s used as a
backup mechanism when they are unable to reach the (external) NTP server.

In the remaining of this tutorial I will demonstrate how to configure NTP on a Cisco router and switches.

Configuration
The router on the top is called “CoreRouter” and its the edge of my network. It is connected to the
Internet and will use one of the NTP servers from pool.ntp.org to synchronize its clock. The network also
has two internal switches that require synchronized clocks. Both switches will become NTP clients of the
CoreRouter, thus making the CoreRouter a NTP server.

Router configuration
First we will configure the CoreRouter on top. I will use pool.ntp.org as the external NTP server for this
example. We need to make sure that the router is able to resolve hostnames:

CoreRouter(config)#ip name-server 8.8.8.8

I will use Google DNS for this. Our next step is to configure the NTP server:

CoreRouter(config)#ntp server pool.ntp.org

That was easy enough, just one command and we will synchronize our clock with the public server. We
can verify our work like this:
Above we see the show ntp associations command that tells us if our clock is synchronized or not. The ~
in front of the IP address tells us that we configured this server but we are not synchronized yet. You can
see this because there is no * in front of the IP address and the “st” field (stratum) is currently 16.

There is one more command that gives us more information about the NTP configuration:

The router tells us that we are unsynchronized and that there is no reference clock…we will just wait a
couple of minutes and take a look at these commands again:

A few minutes later and the output has changed. The * in front of the IP address tells us that we have
synchronized and the stratum is 2…that means that this NTP server is pretty close to a reliable time
source. The “poll” field tells us that we will try to synchronize the time every 64 seconds. Let’s check the
other command that we just saw:

CoreRouter# show ntp status

Our clock has been synchronized and our own stratum is 3, that makes sense since the public stratum
server has a stratum of 2 and we are one “hop” away from it.

NTP synchronization can be very slow so you have to be patient when your clocks are not synchronized.
One way to speed it up a bit is to adjust your clock manually so it is closer to the current time.
Cisco routers have two different clocks, they have a software clock and a hardware clock and they
operate separately from each other. Here’s how to see both clocks:

CoreRouter#show clock

12:41:25.197 UTC Mon Jul 7 2014

CoreRouter#show calendar

12:43:24 UTC Mon Jul 7 2014

The show clock command shows me the software clock while the show calendar command gives me
the hardware clock. The two clocks are not in sync so this is something we should fix, you can do it like
this:

CoreRouter#(config)ntp update-calendar

The ntp update-calendar command will update the hardware clock with the time of the software clock,
here’s the result:

CoreRouter#show clock

12:42:31.853 UTC Mon Jul 7 2014

CoreRouter#show calendar

12:42:30 UTC Mon Jul 7 2014

That’s all I wanted to configure on the CoreRouter for now. We still have to configure two switches to
synchronize their clocks.

Switch Configuration
The two switches will be configured to use the CoreRouter as the NTP server and I will also configure
them to synchronize their clocks with each other. Let’s configure them to use the CoreRouter first:

SW1(config)#ntp server 192.168.123.3

Once again it might take a few minutes to synchronize but this is what you will see:
SW1#show ntp associations

address ref clock st when poll reach delay offset disp

*~192.168.123.3 146.185.130.223 3 21 64 1 2.5 1.02 15875.

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

SW1#show ntp status

Clock is synchronized, stratum 4, reference is 192.168.123.3

nominal freq is 119.2092 Hz, actual freq is 119.2089 Hz, precision is 2**18

reference time is D765271D.D6021302 (14:03:09.835 UTC Mon Jul 7 2014)

clock offset is 1.0229 msec, root delay is 14.31 msec

root dispersion is 16036.00 msec, peer dispersion is 15875.02 msec

The clock of SW1 has been synchronized and its stratum is 4. This makes sense since it’s one “hop”
further away from its NTP server (CoreRouter). Let’s do the same for SW2:

SW2(config)#ntp server 192.168.123.3

Let’s be patient for a few more minutes and this is what we’ll get:

SW2#show ntp associations

address ref clock st when poll reach delay offset disp

*~192.168.123.3 146.185.130.223 3 17 64 37 3.4 1.89 875.8

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

SW2#show ntp status

Clock is synchronized, stratum 4, reference is 192.168.123.3

nominal freq is 119.2092 Hz, actual freq is 119.2084 Hz, precision is 2**18

reference time is D765274D.D51A0546 (14:03:57.832 UTC Mon Jul 7 2014)

clock offset is 1.8875 msec, root delay is 15.18 msec

root dispersion is 1038.39 msec, peer dispersion is 875.84 msec

SW1 and SW2 are now using CoreRouter to synchronize their clocks. Let’s also configure them to use
each other for synchronization. This is the symmetric active mode I mentioned before, basically the two
switches will “help” each other to synchronize…this might be useful in case the CoreRouter fails some
day:

SW1(config)#ntp peer 192.168.123.2

SW2(config)#ntp peer 192.168.123.1

After waiting a few minutes you’ll see that SW1 and SW2 have synchronized with each other:

SW1#show ntp associations

address ref clock st when poll reach delay offset disp

*~192.168.123.3 146.185.130.223 3 59 64 37 3.0 -0.74 877.4

+~192.168.123.2 192.168.123.3 4 50 128 376 2.2 -2.04 1.3

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

SW2#show ntp associations

address ref clock st when poll reach delay offset disp

*~192.168.123.3 146.185.130.223 3 45 128 377 2.9 1.95 1.0

~192.168.123.1 192.168.123.3 4 67 1024 376 1.8 2.40 1.4

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

For Example:

NTP Server
NTP_SVR#show clock
17:56:23.562 UTC Thu Feb 19 2002

NTP_SVR#clock set 10:28:00 SEP 25 2014

NTP_SVR#show clock
10:28:09.923 UTC Thu Sep 25 2014

For NTP server configuration

NTP_SVR#configure terminal
NTP_SVR(config)#ntp master 1

NTP Client
Router2#show clock
*00:21:51.791 UTC Fri Mar 1 2002
Router2#configure terminal
Router2(config)#ntp server 192.168.10.5
Router2(config)#end
Router2#show clock
10:28:11.145 UTC Thu Sep 25 2014

Multicast and Broadcast

If you have more than 20 network devices or a router that has limited system memory or CPU resources
you might want to consider using NTP broadcast or multicast as it requires less resources. We can
enable multicast or broadcast on the interface level.

Router2#configure terminal
Router2(config)#interface fa0/0
Router2(config-if)#ntp broadcast client

How to configure SSH on Cisco IOS

In a previous lesson, I explained how you can use telnet for remote access to your Cisco IOS devices. The
problem with telnet is that everything is sent in plaintext, for that reason you shouldn’t use it.

SSH (Secure Shell) is a secure method for remote access as is includes authentication and encryption. To
do this, it uses a RSA public/private keypair.

There are two versions: version 1 and 2. Version 2 is more secure and commonly used.

Last but not least, to configure SSH you require an IOS image that supports crypto features. Otherwise
you won’t be able to configure SSH.

Let’s configure a hostname:

Router(config)#hostname R1
And a domain name:

R1(config)#ip domain-name NETWORKLESSONS.LOCAL

Now we can generate the RSA keypair:

R1(config)#crypto key generate rsa
The name for the keys will be: R1.NETWORKLESSONS.LOCAL
Choose the size of the key modulus in the range of 360 to 4096 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [512]: 2048

% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 3 seconds)

When you use the crypto key generate rsa command, it will ask you how many bits you want to use for
the key size. How much should you pick?

It’s best to check the next generation encryption article from Cisco for this. At this moment, a key size of
2048 bits is acceptable. Key sizes of 1024 or smaller should be avoided. Larger key sizes also take longer
to calculate.

Once the keypair has been generated, the following message will appear:

R1#

%SSH-5-ENABLED: SSH 1.99 has been enabled

As you can see above, SSH version 1 is the default version. Let’s switch to version 2:

R1(config)#ip ssh version 2

SSH is enabled but we also have to configure the VTY lines:

R1(config)#line vty 0 4

R1(config-line)#transport input ssh

R1(config-line)#login local

This ensures that we only want to use SSH (not telnet or anything else) and that we want to check the
local database for usernames. Let’s create a user:
R1(config)#username admin password my_password

Everything is now in place. We should be able to connect to R1 through SSH now.

SSH Client
The most common SSH client is probably putty. The only thing you have to do is to select the SSH
protocol, enter the IP address and leave the default port at 22:

You will see this on the putty console:

login as: admin

Using keyboard-interactive authentication.

Password:

R1>

You can also use another Cisco IOS device as a SSH client. Here’s how:
R2#ssh ?

-c Select encryption algorithm

-l Log in using this user name

-m Select HMAC algorithm

-o Specify options

-p Connect to this port

-v Specify SSH Protocol Version

-vrf Specify vrf name

WORD IP address or hostname of a remote system

There are quite some options but as a minimum, we should specify a username and IP address:

R2#ssh -l admin 192.168.12.1

Password:

R1>

Syslog

Even if you have never heard of syslog before, you probably have seen it when you worked on a router
or switch. Take a look at the following lines:

R1#
*Feb 14 09:38:48.132: %SYS-5-CONFIG_I: Configured from console by console

R1#
*Feb 14 09:40:09.325: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
*Feb 14 09:40:10.326: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1,
changed state to up

Whenever anything interesting is happening on the router or switch, Cisco IOS informs us in real-time.
This is done by syslog.

By default, these syslog messages are only outputted to the console. This is because the logging console
command is enabled by default. If you log in through telnet or SSH, you won’t see any syslog messages.
You can enable this with the terminal monitor command.

Storing Syslog Messages

Local History
Logging to the console or telnet/SSH is useful if you are around but what if you are not or if you want to
see some older messages? Fortunately for us, Cisco IOS keeps a history of syslog messages. We can see
these with the show logging command:

R1#show logging
Syslog logging: enabled (0 messages dropped, 3 messages rate-limited, 0 flushes, 0 overruns, xml
disabled, filtering disabled)

No Active Message Discriminator.

No Inactive Message Discriminator.

Console logging: level debugging, 34 messages logged, xml disabled,

filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 34 messages logged, xml disabled,
filtering disabled
Exception Logging: size (8192 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled

No active filter modules.

Trap logging: level informational, 38 message lines logged

Logging Source-Interface: VRF Name:

Log Buffer (8192 bytes):

*Mar 1 00:00:01.137: %VIRTIO-3-INIT_FAIL: Failed to initialize device, PCI 0/6/0/1002 , device is

disabled, not supported
*Mar 1 00:00:01.381: %ATA-6-DEV_FOUND: device 0x1F0
*Mar 1 00:00:08.485: %ATA-6-DEV_FOUND: device 0x171
*Mar 1 00:00:08.704: %NVRAM-5-CONFIG_NVRAM_READ_OK: NVRAM configuration 'flash:/nvram' was
read from disk.
*Feb 8 08:51:58.706: %PA-3-PA_INIT_FAILED: Performance Agent failed to initialize (Missing Data
License)
*Feb 8 08:52:05.064: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
*Feb 8 08:52:05.068: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up

Above we can see some syslog messages in our history, it will store up to 8192 bytes of syslog messages
in its RAM. When you reboot your router or switch, the history will be gone. It is possible to increase the
size of the logging buffer. For example:

R1(config)#logging buffered 16384

This reserves up to 16384 bytes of RAM for syslog messages. We can see it here:

R1#show logging | include Log Buffer

Log Buffer (16384 bytes):

Syslog Server
A local history is nice but it is stored in RAM. If you reboot the router or switch, it will be gone. What if
the router crashed and you want to see if it logged anything before it went down? If you have dozens of
routers and switches, logging into each device one-by-one to look for syslog messages is also not the
best way to spend your time.

In production networks, we use a central server called a syslog server. Syslog is a protocol, a standard
and you can configure your routers and switches to forward syslog messages to the syslog server like
this:
Above you can see some syslog messages from 192.168.1.1 (my router). You can also use filters to
search for certain syslog messages and more.

Syslog Severity Levels

Let’s take a closer look at the severity levels. There are different severity levels for logging information.
An interface that goes down is probably more important to know than a message that tells us we exited
the global configuration. In total there are 8 severity levels:

0. Emergency
1. Alert
2. Critical
3. Error
4. Warning
5. Notice
6. Informational
7. Debug

the lower the number, the more important the syslog message is. Alert and emergency are used when
something bad is going on, like when your router runs out of memory and a process crashes. The critical,
error and warning messages are used for important events like interfaces that go down. Here’s an
example:

How to connect Cisco router to syslog server

R1#configure terminal
R1(config)#hostname Router1
Router1(config)#ip domain-name example.com
Router1(config)#interface fastEthernet 0/0
Router1(config-if)#ip address 192.168.10.11 255.255.255.0
Router1(config-if)#no shutdown
Router1(config-if)#exit
Router1(config)#logging source-interface fastEthernet 0/0

fastEthernet 0/0 connected with syslog server

This is considered an important event with severity level 3.

If you are debugging something on the router, then you probably want to see your debug messages on
your console but maybe you don’t want to send those same messages to your syslog server or to the
router’s local syslog history. Cisco IOS allows you to define what syslog messages you want to see, save
or send to the syslog server. For example:

Router1(config)#logging trap ?
<0-7> Logging severity level
alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
debugging Debugging messages (severity=7)
emergencies System is unusable (severity=0)
errors Error conditions (severity=3)
informational Informational messages (severity=6)
notifications Normal but significant conditions (severity=5)
warnings Warning conditions (severity=4)

Router1(config)#logging trap 5

Lastly enable logging

Router1(config)#logging on
Router1(config)#exit

The Simple Network Management Protocol (SNMP) is a necessary tool for every network administrator.
You can easily configure it with just a few commands.

SNMP is still the most popular way to monitor the performance of network devices, including Cisco
routers and switches. With an SNMP management station, you can graph the performance of network
devices. In addition, Cisco devices can send alerts (called traps) to the management station, which you
can configure to alert you.

What is SNMP?
There are three versions of SNMP -- v1, v2, and v3. Each has more features than the next. Most network
admins today use v2, but v3 offers many more security features.

How does SNMP work? SNMP devices contain configured SNMP agents. The network management
system (NMS) talks to the SNMP agents on each device.
The NMS could be a huge system such as HP OpenView or an application that's only there to track
performance such as PRTG . For more detailed information on how SNMP works, check out
Cisco's Simple Network Management Protocol (SNMP) white paper.

SNMP runs on the application layer and consists of a SNMP manager and a SNMP agent. The SNMP
manager is the software that is running on a pc or server that will monitor the network devices, the
SNMP agent runs on the network device.

The database that I just described is called the MIB (Management Information Base) and an
object could be the interface status on the router (up or down) or perhaps the CPU load at a certain
moment. An object in the MIB is called an OID (Object Identifier).

The SNMP manager will be able to send periodic polls to the router and it will use store this information.
This way it’s possible to create graphs to show you the CPU load or interface load from the last 24 hours,
week, month or whatever you like.

It’s also possible to configure your network devices through SNMP. This might be useful to configure a
large number of switches or routers from your network management system so you don’t have to
telnet/ssh into each device separately to make changes.

The packet that we use to poll information is called a SNMP GET message and the packet that is used to
write a configuration is a SNMP SET message.

Network Management System

To give you an example of what a NMS looks like, I’ll show you some screenshots of Observium.

Observium is a free SNMP based network monitoring platform which can monitor Cisco, Linux, Windows
and some other devices. It’s easy to install so if you never worked with SNMP or monitoring network
devices before I can highly recommend giving it a try. You can download it
at http://www.observium.org.
PRTG
SNMPv3 is similar to SNMPv1 or SNMPv2 but has a completely different security model. SNMPv1 and
SNMPv2 use a community-string that is used as the password and there’s no authentication or
encryption.

SNMPv3 is able to use both authentication and encryption and has a new security model that works with
users, groups and 3 different security levels. Users will be applied to a group and access policies will be
applied to a group so that you can determine what groups have read or read-write access and which
MIBs (Management Information Bases) they should be able to access.

Security Levels

SNMP offers 3 different security levels:

 noAuthNoPriv
 AuthNoPriv
 AuthPriv

Auth stands for Authentication and Priv for Privacy (encryption).

 noAuthNoPriv = username authentication and no encryption.

 AuthNoPriv = MD5 or SHA authentication but no encryption.
 AuthPriv = MD5 or SHA authentication AND encryption.
 SNMPv1 and SNMPv2 only support noAuthNoPriv since they don’t offer any authentication or
encryption. SNMPv3 supports any of the three security levels. When you decide to use noAuthNoPriv for
SNMPv3 then the username will replace the community-string.

The community-string for SNMPv1 and SNMPv2 is send in clear-text. SNMPv3 is far more secure because
it doesn’t send the user passwords in clear-text but uses MD5 or SHA1 hash-based authentication,
encryption is done using DES, 3DES or AES.

Let’s take a look at a simple SNMPv3 configuration example on a Cisco IOS router.

How can SNMP help me?

SNMP can do a variety of things. Here are some ways it has helped me:

 It can graph Cisco router/switch bandwidth utilization over time, per interface, per direction, etc.
 It can graph errors on network devices (e.g., CRC errors).
 It can send alerts when an interface goes up or down.

Enabling SNMP in Cisco Routers / Switches

Summary

This article will guide your through the steps to enable SNMP in Cisco Routers and Switches

Description

1. Telnet to the router/switch

prompt#telnet testrouter
2. Go to the enable mode by specifying the password:

Router>enable
Password:
Router#
3. Go into configuration mode:

Router#configure terminal
Enter configuration commands, one per line. End
with CNTL/Z.
Router(config)#
4. Use the command below to add a Read-Only community string:
 Router(config)#snmp-server community public RO
where "public" is the Read-only community string.
5. To add a Read-Write Community string, use the command below:

Router(config)#snmp-server community private RW

where "private" is the Read-write community string.
6. Exit the configuration mode and save the settings:

Router(config)#exit
Router#write memory
Building configuration...
[OK]
Router#

To enable SNMP traps, follow the steps below in the Configuration mode of the Router/Switch:

First, set the host to which the traps have to be sent using the folowing command:
snmp-server host <IP Address> version <v1 or 2c> <RO community string>
where,
<IP Address> refers to the IP Address of the device to which the traps have to be sent
<v1 or 2c> refers to the SNMP version
<RO community string> refers to the Read-Only community string
Then, enable SNMP Traps using the command below:
snmp-server enable traps [notification-type] [notification-option]
Ex: snmp-server enable traps config [this will send all configurationnotifications as traps]