EXAMPLE SCENARIO

This article will show you how to configure your Cisco router to synchronise its software clock from
external sources such as NTP servers. We will also show you how to configure your router to act as
an NTP server for your internal network devices, ensuring all devices are synchronised.

First example involves setting up the router to request NTP updates and synchronise itself from a
public NTP server. This will ensure the router's time is constantly synchronised, however it will not
act as an NTP server for internal hosts:

We'll need to configure the router to resolve FQDN using our ISP's name server:

R1(config)# ip nameserver 195.170.0.1

Now we instruct our Cisco router to obtain its updates from the public NTP server.

R1(config)# ntp server 1.gr.pool.ntp.org

As soon we issue the command, the router will resolve the FQDN into an ip address and begin its
synchronisation. Right after issuing the command, we can verify the router is correctly configured
and awaiting synchronisation:

R1# show ntp associations

   address             ref clock           st     when    poll    reach     delay      offset      disp
~195.97.91.220   131.188.3.221   2      30        64       1        0.000     -1539.9    7937.5
* sys.peer,  # selected, + candidate, - outlyer, x falseticker, ~ configured

R1# show ntp status

Clock is unsynchronised, stratum 16, no reference clock
nominal freq is 250.0000 Hz, actual freq is 250.0006 Hz, precision is 2**24
reference time is 00000000.00000000 (02:00:00.000 Greece Mon Jan 1 1900)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec
loopfilter state is 'FSET' (Drift set from file), drift is -0.000002405 s/s
system poll interval is 64, never updated.

The 'show ntp associations' command shows that the system is configured (~) to synchronise with
our selected NTP server, however, it is not yet synchronised. When it is, expect to see the star (*)
symbol in front of the tilde (~). The 'ref. clock' column shows the IP address of the NTP server from
which our public server (1.gr.pool.ntp.org) is synchronising.

It is also worth noting the column named 'st' which is equal to two (2). This represents the stratum
level. The higher the stratum, the closer to the Atomic clock source we are. As a general rule,
always try to synchronise with a server that has a low stratum.

The 'show ntp status' command confirms that we are yet to be synchronised with the NTP server
as it clearly states that the 'clock is unsynchronised' and also shows us the current system time: 1st
of Jan. 1900.

After a couple of minutes, we re-visit the CLI prompt and re-issue the commands with the following
results:

R1# show ntp associations

   address               ref clock           st       when      poll     reach     delay    offset      disp
*~195.97.91.220  131.188.3.221    2        19          64      377      0.000    -59.272   5.317
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

R1# show ntp status

Clock is synchronised, stratum 3, reference is 212.251.14.84 
nominal freq is 250.0000 Hz, actual freq is 250.0007 Hz, precision is 2**24
reference time is CD94CFEB.901B3679 (01:17:15.562 Athens Sun Apr 19 2009)
clock offset is -0.0592 msec, root delay is 0.09 msec
root dispersion is 0.12 msec, peer dispersion is 0.00 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000003099 s/s
system poll interval is 64, last update was 476 sec ago.

Looking at the new output, we can see that our Cisco router is now synchronising with the
configured peer (*) - public NTP server. Polling of the public NTP server will occur every 64
seconds, as shown in the command output.

The 'show ntp status' command also confirms the synchronisation, however, notice that the router
has set its stratum level to 3. This is expected as the reference is stratum 2. The time is now
correctly shown (01:17:15.562 Athens Sun Apr 19 2009).

SYNCHRONISING SOFTWARE CLOCK AND HARDWARE CLOCK

Here we'll see how in fact the software and hardware clocks on a Cisco router can have different
times and how we can synchronise them between each other.

The following two commands show the difference in time between the two clocks on our Cisco
router:

R1# show clock 
01:51:31.532 Athens Sun Apr 19 2009
R1# show calendar 
01:51:42 Athens Sun Apr 19 2009

While the difference is minor, we want to keep everything in our network synchronised as precisely
as possible.

Keep in mind that 'show clock' refers to the software clock and 'show calendar' refers to the
hardware clock of your router.

To synchronise the two clocks all we need to do is issue the following command:

R1# configure terminal
R1(config)# ntp update-calendar

The 'ntp update-calendar' forces the hardware clock to synchronise with the system's software
clock. After a couple of minutes, we check to see if the two clocks have synchronised:

R1# show clock 
02:07:05.011 Athens Sun Apr 19 2009

R1# show calendar 
02:07:05 Athens Sun Apr 19 2009

We can see now that both clocks are accurately synchronised.

CONFIGURING THE SYSTEM AS AN AUTHORITATIVE NTP SERVER

If you want your system to become an authoritative NTP server from which other internal routers or
machines can synchronise, you can achieve this with the following command:

R1(config)# ntp master

The router now acts as an NTP server and is able to respond to internal clients NTP requests.
Checking the 'ntp association' will reveal that the router is obtaining its time synchronisation from
itself:

R1# show ntp associations

address                ref clock           st.   when    poll    reach    delay    offset     disp
*~127.127.1.1      LOCL.               7      4        16      377     0.000    0.000     0.253
~195.97.91.220   131.188.3.221   2      64       64       1       0.000  -179.09    7937.5
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

TROUBLESHOOTING AND MONITORING NTP STATUS

Troubleshooting NTP messages and events is important when you are trying to verify everything is
working correctly. You might notice that your Cisco router is not able to create a peer connection
with a configured NTP server or your internal LAN clients might not be able to synchronise with your
Cisco router; In any case, knowing how to troubleshoot NTPs is something every engineer must be
aware of.

Thankfully Cisco provides a number of options that allow you to troubleshoot many aspects of your
NTP service.

R1# debug ntp ? 
adjust NTP clock adjustments
all NTP all debugging on
core NTP core messages
events NTP events
packet NTP packet debugging
refclock NTP refclock messages

The most useful debug commands are the 'debug ntp events', 'debug ntp adjust' and 'debug ntp
core'. These three commands provide enough debugging to help you troubleshoot problems you
might encounter.

Closing, if you would like more information on the ntp associations created by your router you can
try the following command:

R1# show ntp associations detail 

195.97.91.220 configured, our_master, sane, valid, stratum 2
ref ID 131.188.3.221 , time CD94E194.58EA9A78 (02:32:36.347 Athens Sun Apr 19 2009)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.05 msec, root disp 41.32, reach 377, sync dist 0.16
delay 0.00 msec, offset -292.8879 msec, dispersion 3.02
precision 2**20, version 4
org time CD94E561.D6FE7162 (02:48:49.839 Athens Sun Apr 19 2009)
rec time CD94E562.287A2A0D (02:48:50.158 Athens Sun Apr 19 2009)
xmt time CD94E562.22E5E145 (02:48:50.136 Athens Sun Apr 19 2009)
filtdelay = 0.02 0.02 0.02 0.02 0.02 0.02 0.02 0.02
filtoffset = -0.30 -0.30 -0.29 -0.28 -0.27 -0.27 -0.26 -0.25
filterror = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
minpoll = 6, maxpoll = 10

The 'show ntp associations detail' command will provide much information on the association
created with the NTP servers. This is most helpful when you see you are unable to create an
association with an NTP server.