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

This is the topology I will use:

cisco ntp example topology

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:

CoreRouter#show ntp associations 

  address         ref clock       st   when   poll reach  delay  offset   disp
 ~146.185.130.223 .INIT.          16      -     64     0  0.000   0.000 16000.
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

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:

CoreRouter#show ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.16 msec, peer dispersion is 0.00 msec
loopfilter state is 'FSET' (Drift set from file), drift is 0.000000000 s/s
system poll interval is 64, never updated.

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:

CoreRouter#show ntp associations 

  address         ref clock       st   when   poll reach  delay  offset   disp
*~146.185.130.223 193.79.237.14    2     26     64     1 10.857  -5.595 7937.5
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

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       
Clock is synchronized, stratum 3, reference is 146.185.130.22
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is D76513B4.66A4CDA6 (12:40:20.400 UTC Mon Jul 7 2014)
clock offset is -5.5952 msec, root delay is 13.58 msec
root dispersion is 7966.62 msec, peer dispersion is 7937.50 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000000018 s/s
system poll interval is 64, last update was 43 sec ago.

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

Great everything is now in sync.

Configurations

Want to take a look for yourself? Here you will find the configuration of each device.

CoreRouter

hostname CoreRouter
!
interface FastEthernet0/0
 ip address 192.168.123.3 255.255.255.0
!
ip name-server 8.8.8.8
!
ntp server pool.ntp.org
ntp update-calendar
!
end

SW1

hostname SW1
!
interface FastEthernet0/24
 ip address 192.168.123.1 255.255.255.0
!
ntp server 192.168.123.3
ntp peer 192.168.123.2
!
end

SW2

hostname SW2
!
interface FastEthernet0/24
 ip address 192.168.123.2 255.255.255.0
!
ntp server 192.168.123.3
ntp peer 192.168.123.1
!
end


Are we done? Not quite yet…there are a few more things we can do with NTP. The CoreRouter and the two switches use unicast (UDP port 123) for synchronization but you can also use multicast or broadcast. Let me give you an example…

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.To demonstrate this I will add two routers below SW1 and SW2 that will synchronize themselves using multicast or broadcast. This is what it looks like:

cisco ntp broadcast multicast example topology

I’ll configure SW1 to use multicast address 239.1.1.1 and SW2 will send NTP updates through broadcast:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 657 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

539 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Hello Guy!

    The first complete specification of NTP, that is, Version 1, appeared in 1988 (RFC 1059) which provided simple symmetric and client server mode operation.

    Version 2 appeared in 1989 (RFC 1119) and added symmetric key authentication using DES-CBC.

    Version 3, which is the version that is most used today was first described in 1992 (RFC 1305) and has been systematically improved over the years. It introduced formal correctness principles, revised algorithms and broadcast mode . This is the default version that is available in most Cisco devices using

    ... Continue reading in our forum

  2. Hello Laz,
    A few questions.

    1. Let’s say I have a router that is configured to receive the ntp information from a ntp server located in the internet. I have also configured the time locally by using clock set command. Which time will have more preference? In another words, which time the router will use?
    2. What is the command to change time-zone in a router?
    3. Let’s say a router is configured to sync its time from a ntp server and the ntp server is feeding UTC time to the router. However, I like the router to show EST time in the clock or let’s say in syslog message
    ... Continue reading in our forum

  3. Hello AZM

    **Question 1**
    When NTP is configured on a device, there is what is called a poll interval. This interval is dynamic and as client and server become better synced, and there aren’t any dropped packets, this interval increases to a maximum of 1024 seconds. If you change the time using the clock set command, the time you set will become the new time. However, when the poll interval is exhausted, the device will re-sync with the NTP server. So any changes you make manually will be over-ridden at the next poll interval.

    **Question 2**
    To change the ti

    ... Continue reading in our forum

  4. Hi Sreenath,

    NTP and PTP have some similarities. NTP is the most common protocol to sync clocks on your network, that’s what you will mostly see on networks nowadays. We use it to sync the clock on network devices but also computers/servers etc. NTP uses software timestamping and supports millisecond synchronization.

    PTP is similar to NTP but uses hardware timestamping and offers nanosecond or picosecond-level synchronization.

    For 99% of the devices, NTP is good enough but if you have devices where millisecond-level synchronization is not good enough, PTP is an

    ... Continue reading in our forum

  5. Hello Kevin,

    NTP authentication can be confusing. With your configuration, no authentication occurs because the client isn’t configured for authentication. I did a quick lab with your configuration.

    The server will send “regular” NTP packets without an MD5 hash. Once you change the ntp server command on the client, it works.

    Before:

    https://www.cloudshark.org/captures/c40ea3a2748b

    After:

    Client(config)#ntp server 192.168.1.1 key 1

    https://www.cloudshark.org/captures/e016b1c2e8a8

    Once the client wants to use authentication, the server responds with the same MD5

    ... Continue reading in our forum

54 more replies! Ask a question or join the discussion by visiting our Community Forum