Notte: This article assumes you already know what is the NTP protocol and its related concepts.
Configuring a cisco IOS router as an NTP client requires implementing the below commands,
1. Setting up the timezone, in this case we’ll consider Italy’s timezone which is CET (GMT +1)
We’ll set the dayklight savins using the summer time-zone command
clock timezone CET 1 clock summer-time CEST recurring
2. Configuring the NTP server & it can be inserted as an IP in case it’s an internal Server or a public server with a static IP
ntp server 192.168.10.1 primary ntp server 10.1.1.1
3. You may set up an external server using its FQDN, but this will require enabling dns lookup and configuring a dns server.
ntp server 0.it.pool.ntp.org
! Enabling domain lookups ip domain lookup ! Setting up a public or private dns server ip name-server 22.214.171.124
This should be all what’s required for configuring it. Now what if it’s not working as expected?!
There are couple of commands you can use the correct behavior
- show clock command (The below date is not correct)
R1#show clock *00:51:14.755 UTC Fri Mar 1 2002
- show ntp status (Shows it as unsynchronized)
R1#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**18 reference time is 00000000.00000000 (01:00:00.000 CET 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
- show ntp associations (All the counters are on their default values “mostly zeroes”)
R1#show ntp associations address ref clock st when poll reach delay offset disp ~126.96.36.199 0.0.0.0 16 - 64 0 0.0 0.00 16000. ~188.8.131.52 0.0.0.0 16 - 64 0 0.0 0.00 16000. * master (synced), # master (unsynced), + selected, - candidate, ~ configured
So, The 1st thing to troubleshoot is the reachability of the NTP servers from the router. In case true, but the traffic is exiting from the wrong vrf/interface You may explicitly set the source interface of the NTP and/or dns traffic.
ntp source eth0/0 ip domain lookup source-interface eth0/0
It may take couple minutes to Sync, So just relax 🙂
Debugging all the NTP events is very useful in this situation, as it directly point you to the ause of the issue.
R1#debug ntp events ! Sample output *Mar 1 01:31:02.927: NTP: synced to new peer 184.108.40.206 *Dec 30 22:31:29.456: NTP: peer stratum change *Dec 30 22:31:29.456: NTP: clock reset Dec 30 22:32:33.444: NTP: synced to new peer 220.127.116.11 Dec 30 22:32:33.444: NTP: 18.104.22.168 synced to new peer Dec 30 22:32:33.444: NTP: sync change Dec 30 22:32:33.444: NTP: peer stratum change Dec 30 22:32:33.444: NTP: 22.214.171.124 reachable
Example output for properly functioning NTP client
R1#show ntp status Clock is synchronized, stratum 3, reference is 126.96.36.199 nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18 reference time is E1B50149.7E7DCF6F (00:05:45.494 CET Tue Dec 31 2019) clock offset is -17.9100 msec, root delay is 49.50 msec root dispersion is 48.57 msec, peer dispersion is 5.07 msec R1#show ntp associations address ref clock st when poll reach delay offset disp +~188.8.131.52 184.108.40.206 2 80 128 377 24.1 -28.17 3.9 *~220.127.116.11 18.104.22.168 2 42 128 377 36.1 -7.65 5.1 * master (synced), # master (unsynced), + selected, - candidate, ~ configured R1#
This should cover the basic NTP configurations and troubleshooting.
Setting secure and supporting authentication with NTP servers is not covered in this topic.