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.
Ex:

ntp server 0.it.pool.ntp.org

will require

! Enabling domain lookups
ip domain lookup
! Setting up a public or private dns server
ip name-server 1.1.1.1

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

  1. show clock command (The below date is not correct)
R1#show clock
*00:51:14.755 UTC Fri Mar 1 2002
  1. 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
  1. 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
~212.45.144.3 0.0.0.0 16 - 64 0 0.0 0.00 16000.
~31.14.133.122 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.
Ex:

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 31.14.133.122
*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 31.14.133.122
Dec 30 22:32:33.444: NTP: 31.14.133.122 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: 31.14.133.122 reachable

Example output for properly functioning NTP client

R1#show ntp status 
Clock is synchronized, stratum 3, reference is 31.14.133.122
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
+~212.45.144.3     193.204.114.232   2    80   128  377    24.1  -28.17     3.9
*~31.14.133.122    193.204.114.233   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.