Skip to main content

Lab 3-2: Network Time Protocol

image.pngTopology diagram for this lab

Equipment Required

  • Cisco 2821 router
  • Cisco 3560 switch

Objectives

Configure NTP


Scenario

JRI wants its new data network to use NTP to synchronize time for network devices. NTP is not only important for synchronizing the time in network device event logs, but also for VoIP to show the correct time on the display of the phones and record the correct timestamp on voicemails, among other uses. The best way to keep everything synchronized is to use an NTP server to coordinate time.


Task 1: NTP Services

Configure Local Time Zone
RtrPod1(config)# clock timezone CET +1
RtrPod1(config)# clock summer-time CEST recurring last Sunday March 02:00 last Sunday October 02:00
Manually Set the Clock

By manually setting the clock close to the correct time, you reduce the amount of time it takes to synchronize with the NTP server. Ideally, you should be within a minute or two of the correct time.

RtrPod1#clock set 19:40:00 29 June 2025
RtrPod1#
*Jun 29 17:40:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 03:18:10 CET Sat Jan 1 2000 to 19:40:00 CEST Sun Jun 29 2025, configured from console by console.
Contact an NTP Server on the Internet

I will bring up the Gi0/1 interface on the 2821 which is now connected to my home router, and configure it to get an IP address from a DHCP server (the home router). I will also need to configure static default route pointing to my home router LAN IP address:

RtrPod1# conf t
RtrPod1(config)# interface GigabitEthernet 0/1
RtrPod1(config-if)# ip address dhcp
RtrPod1(config-if)# no shutdown
RtrPod1(config-if)# exit
RtrPod1(config)# ip domain-lookup
RtrPod1(config)# ip name-server 8.8.8.8
RtrPod1(config)# ntp server es.ntp.pool.org
Verify That the Time is Syncrhonized

It can take five to ten minutes to synchronize with the NTP server. To avoid overwhelming NTP servers, the router starts by polling the server every 64 seconds, and it takes several poll intervals for the router to establish confidence in the results.

RtrPod1#show ntp associations

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

The INIT phase can take up to a minute (64s as poll interval default). After this, the router will show the difference between the NTP server time and the time on the router. The router is now establishing the variation in time between the received time and local time. At the point the incrementing "when" counter equals the "poll" number, the NTP server will be queried again.

!!! See how the "when" counter goes up every time I execute the command

RtrPod1#show ntp associations

  address         ref clock       st   when   poll reach  delay  offset   disp
 ~51.145.123.29   10.0.6.20        3     30     64     3  0.000   8.628 3937.9
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
RtrPod1#show ntp associations

  address         ref clock       st   when   poll reach  delay  offset   disp
 ~51.145.123.29   10.0.6.20        3     32     64     3  0.000   8.628 3937.9
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
RtrPod1#show ntp associations

  address         ref clock       st   when   poll reach  delay  offset   disp
 ~51.145.123.29   10.0.6.20        3     35     64     3  0.000   8.628 3937.9
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

If we setup a debug ntp all we can see the NTP events between the router and the NTP server:

RtrPod1#
.Jun 29 18:33:26.908: NTP message sent to 51.145.123.29, from interface 'GigabitEthernet0/1' (192.168.1.152).
.Jun 29 18:33:26.940: NTP message received from 51.145.123.29 on interface 'GigabitEthernet0/1' (192.168.1.152).
.Jun 29 18:33:26.940: NTP Core(DEBUG): ntp_receive: message received
.Jun 29 18:33:26.940: NTP Core(DEBUG): ntp_receive: peer is 0x474E1CE8, next action is 1.
.Jun 29 18:33:26.940: NTP Core(DEBUG): receive: packet given to process_packet
.Jun 29 18:33:26.944: NTP Core(DEBUG): Peer becomes reachable, poll set to 6.

.Jun 29 18:33:26.944: NTP Core(INFO): peer 51.145.123.29 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014)

 

The next phase is to accept the time from the NTP server and establish the accuracy of the local clock. Notice that router is over 8 milisecs. off from the NTP server.

RtrPod1#show ntp associations detail
51.145.123.29 configured, insane, invalid, stratum 3
ref ID 10.0.6.20     , time EC0C0529.28ED641C (20:32:09.159 CEST Sun Jun 29 2025)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.01 msec, root disp 28.64, reach 7, sync dist 2.00
delay 0.00 msec, offset 8.6281 msec, dispersion 1938.71
precision 2**23, version 4
org time EC0C05F7.F0DD0884 (20:35:35.940 CEST Sun Jun 29 2025)
rec time EC0C05F7.F1F5AD95 (20:35:35.945 CEST Sun Jun 29 2025)
xmt time EC0C05F7.E88430E9 (20:35:35.908 CEST Sun Jun 29 2025)
filtdelay =     0.03    0.03    0.03    0.00    0.00    0.00    0.00    0.00
filtoffset =    0.01    0.01    0.00    0.00    0.00    0.00    0.00    0.00
filterror =     0.00    0.00    0.00   16.00   16.00   16.00   16.00   16.00
minpoll = 6, maxpoll = 10

After enough polls have been completed, the time on the router is NTP synchronized. Your router now considers the NTP server “our master, sane, and valid.”

.Jun 29 18:37:46.944: NTP Core(INFO): system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_ntp, 1 event, event_unspec' (0xC610)
.Jun 29 18:37:46.944: NTP Core(INFO): synchronized to 51.145.123.29, stratum 3
.Jun 29 18:37:46.944: NTP Core(INFO): system event 'event_sync_chg' (0x03) status 'leap_none, sync_ntp, 2 events, event_peer/strat_chg' (0x624)
.Jun 29 18:37:46.944: NTP Core(NOTICE): Clock is synchronized.
Jun 29 18:37:46.944: NTP Core(INFO): system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_ntp, 3 events, event_sync_chg' (0x633)

RtrPod1#show ntp status
Clock is synchronized, stratum 4, reference is 51.145.123.29
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is EC0C067A.F2314251 (20:37:46.946 CEST Sun Jun 29 2025)
clock offset is 0.0086 msec, root delay is 0.04 msec
root dispersion is 0.48 msec, peer dispersion is 0.44 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000000000 s/s
system poll interval is 64, last update was 41 sec ago.

RtrPod1#show ntp associations

  address         ref clock       st   when   poll reach  delay  offset   disp
*~51.145.123.29   10.0.6.20        3     53     64    37  0.000   8.628 440.43
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
Configure the Switch to get NTP from the Router

For the sake of making sure that all networking devices are synched using NTP, the switch should use the router as an NTP source. To avoid overloading public NTP time servers, common practice has only a few edge devices at a company contact the public NTP servers, and all other company resources contact those edge devices.

First step, the router should be configured as an NTP master to serve time:

RtrPod1(config)#ntp master

The configuration of the switch is as follows:

SwPod1(config)# clock timezone CET +1
SwPod1(config)# clock summer-time CEST recurring last Sunday March 02:00 last Sunday October 02:00
SwPod1(config)# ntp server 10.11.0.1

Verification:

SwPod1#show ntp status
Clock is synchronized, stratum 5, reference is 10.11.0.1
nominal freq is 119.2092 Hz, actual freq is 119.2114 Hz, precision is 2**17
reference time is EC0C07BF.634FBF01 (20:43:11.387 CEST Sun Jun 29 2025)
clock offset is 0.2534 msec, root delay is 48.16 msec
root dispersion is 84.34 msec, peer dispersion is 0.09 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000017978 s/s
system poll interval is 64, last update was 5 sec ago.