NTP: Demonstrated between 2 routers running IOS 15.x to demonstrate NTPv4 Authentication and other concepts! (Edited with more content 5/20/17)

As I only have two routers in my lab running IOS 15.x, and 12.x is not NTPv4 capable, I’ve decided to review it between just these two routers to demonstrate new features brought by 15.x code that I couldn’t in my previous lab involving the whole WAN Topology.

To start there are a quite a few things we require a network with synchronized time for:

• Phone Systems absolutely require synchronized time across the network
• Debugging output and logging files to compare to current “sh clock” time
• Network Mgmt Protocols (Like SNMP)

Just to name a few, beyond just logs and such, it is absolutely necessary for phone systems to have as accurate a time as it can have without be hooked directly to an Atomic Clock.

Also, if you’ve ever pulled logs with the completely wrong time set, and had to do “sh clock” and try to piece the logs to the current time like a puzzle it quickly turns into a very frustrating waste of time when you’re busy.

That being said, all routers have a built in “System Clock” which is usually battery driven, so if you power cycle the router it will retain the correct time (not all, but most routers).

When a router is pulled out of the box, it has a default time that is probably very different from the current time, and needs to be configured in one of the following ways:

• Manual Configuration – Configuring the time directly on the device
• NTP (Network Time Protocol) – Getting Time from a Time Source
• SNTP (Simple Network Time Protocol) – Receive only protocol for Time

Given that NTP can both receive and send network time to other devices, we will not discuss SNTP at all, but wanted to mention it because it is a thing (though I’ve never seen it in production networks).

The two major versions in use of NTP are Version 3 and Version 4, and the ROUTE exam will expect you to know some differences between them, in terms of what was introduced in NTPv4 (which is why I’m using 15.x routers only).

So lets get to the differences between the two versions right up front:

Version 3

• Only worked with IPv4, not IPv6
• Does not do Authentication
• Both use UDP Port 123 for source and destination

Version 4

• Introduces NTP Authentication
• Works with IPv4 and IPv6
• Again both uses UDP Port 123 as source and destination

NTP devices, aside from manually configuring a Master / Server source in your network, obtains their time from a reliable source. This can be an Atomic Clock (unlikely unless you have access to Military grade Atomic Clocks), NTP Servers available via ntp.org, or other network devices like a manually configured device.

NTP is 100% Client / Server model protocol, where the client polls the Server for time about every minute, and the Server (considered to be the Authortive Source for time) provides time to that Client.

The Authority that a Time Server has is based on something called Stratum, which is a measurement of hops away from an Atomic Clock, so a device directly connected to an Atomic Clock is a Stratum 1, another device 1 hop away from a Stratum 1 device is a Stratum 2.

So as can be seen, the Stratum increments based on where you get your time from, for example if my router gets it’s time from a Stratum 3 clock then it is Stratum 4.

When configuring a router manually to be an NTP server, it’s default stratum level if not defined, is Stratum 8 with no real explanation as to why – So you’ll want to set it to a lower value.

There are 4 different modes of NTP devices

• NTP Server (Also referred to as a Master)
• NTP Client
• NTP Peers (Called Symmetric mode, two or more NTP servers that exchange information)
• NTP Broadcast / Multicast mode (Can be configured on the Server or Client as a “push” or poll of time in either Broadcast or Multicast format of transmission)

So, all that being said, first lets look at how to manually configure our NTP Server:

R1#clock set ?
  hh:mm:ss  Current Time

R1#clock set 18:34:00 ?
  <1-31>  Day of the month
  MONTH   Month of the year

R1#clock set 18:34:00 May ?
  <1-31>  Day of the month

R1#clock set 18:34:00 May 19 ?
  <1993-2035>  Year

R1#clock set 18:34:00 May 19 2017 ?
  <cr>

R1#clock set 18:34:00 May 19 2017
R1#
*May 19 18:34:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 00:29:07 UTC Sat May 20 2017 to 18:34:00 UTC Fri May 19 2017, configured from console by console.
R1#

As you can see, Cisco has predicated at the time of the making of this router, our species will either not make it past the year 2035, or figured the device would be antiquated by then. I agree with both theories.

So now that a network device has the correct time, we should make that the Server for the network, and assign it a proper Stratum:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ntp master ?
  <1-15>  Stratum number
  <cr>

R1(config)#ntp master 1
R1(config)#

As can be seen this is done in Global Configuration mode, which also has a couple of optional commands that can be entered here as well:

R1(config)#ntp peer 172.12.14.4 ?
  burst        Send a burst when peer is reachable
  iburst       Send a burst when peer is unreachable
  key          Configure peer authentication key
  maxpoll      Maximum poll interval
  minpoll      Minimum poll interval
  normal-sync  Disable rapid sync at startup
  prefer       Prefer this peer when possible
  source       Interface for source address
  version      Configure NTP version
  <cr>

R1(config)#ntp peer 172.12.14.4
R1(config)#int fa0/1
R1(config-if)#ntp ?
  broadcast  Configure NTP broadcast service
  disable    Disable NTP traffic (both IP and IPv6)
  multicast  Configure NTP multicast service

R1(config-if)#

So as shown the “ntp peer” command is entered now on the global config level, and I did go into the interface level to show the broadcast / multicast command, but did not issue it.

So now that R1 is saying its an NTP Peer with R4, lets issue that on R4 and see if it synchronizes:

R4#debug ntp events
NTP events debugging is on
R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#ntp peer 172.12.14.1
R4(config)#
*May 19 23:40:26.315: %NTP : Drift Read : FFFFFFFF.FFFFD70D
*May 19 23:40:26.315: NTP: Initialized interface FastEthernet0/0
*May 19 23:40:26.315: NTP: Initialized interface FastEthernet0/1
*May 19 23:40:26.315: NTP: Initialized interface Loopback4
*May 19 23:40:26.315: NTP: Initialized interface VoIP-Null0
R4(config)#do sh clock
*23:40:35.299 UTC Fri May 19 2017
R4(config)#

This can be configured between NTP Servers, or between Server / Client, depending on whether you who you want to keep on the same page of what Time it is. Now lets try the interface level Broadcast command facing R4:

R4(config)#no ntp peer 172.12.14.1
R4(config)#
ASR#1
[Resuming connection 1 to r1 … ]

R1(config)#no ntp peer 172.12.14.4
R1(config)#int fa0/1
R1(config-if)#ntp broadcast
R1(config-if)#
ASR#4
[Resuming connection 4 to r4 … ]

.May 19 18:59:54.540: NTP: Uninitialized interface FastEthernet0/0
.May 19 18:59:54.540: NTP: Uninitialized interface FastEthernet0/1
.May 19 18:59:54.540: NTP: Uninitialized interface Loopback4
.May 19 18:59:54.540: NTP: Uninitialized interface VoIP-Null0
R4(config)#do sh clock
.19:00:35.060 UTC Fri May 19 2017
R4(config)#

Again without any Authentication or anything set, the Server broadcasts its time at a non-server (client) and it immediately syncs its time with the Server.

Remember, Peer and Broadcast are completely optional!

So I’ve removed all those settings, and we are back to the R4 having no Time Source information configured but R1 is our Stratum 1 NTP Server, lets look at the client configuration.

There are two ways to really go about requesting time from the Server:

• “ntp server (master IP)”
• “ntp broadcast client”

My IOS doesn’t seem to support the second command (dag nab it), so lets look at the first:

R4(config)#ntp server 172.12.14.1
R4(config)#
.May 19 19:08:12.908: %NTP : Drift Read : FFFFFFFF.FFFFD70D
.May 19 19:08:12.912: NTP: Initialized interface FastEthernet0/0
.May 19 19:08:12.912: NTP: Initialized interface FastEthernet0/1
.May 19 19:08:12.912: NTP: Initialized interface Loopback4
.May 19 19:08:12.912: NTP: Initialized interface VoIP-Null0
R4(config)#

R4 is of course still running “debug ntp events”, and if I remove the command:

R4(config)#no ntp server 172.12.14.1
R4(config)#
.May 19 19:08:26.472: NTP: Uninitialized interface FastEthernet0/0
.May 19 19:08:26.472: NTP: Uninitialized interface FastEthernet0/1
.May 19 19:08:26.472: NTP: Uninitialized interface Loopback4
.May 19 19:08:26.472: NTP: Uninitialized interface VoIP-Null0
R4(config)#

So from this output we gather Initialized = Good, Uninitialized = Bad with NTP.

The two verification commands for NTP as I’ve covered before will be:

• “sh ntp status”
• “sh ntp assoc”

So I’ll re-apply the server command to R4 pointing it to R1 again, and lets see what the output looks like on R4:

R4(config)#do sh ntp status
Clock is unsynchronized, 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 (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.10 msec, peer dispersion is 0.00 msec
loopfilter state is ‘FSET’ (Drift set from file), drift is -0.000002440 s/s
system poll interval is 64, never updated.
R4(config)#
R4(config)#
R4(config)#
R4(config)#do sh ntp assoc

  address         ref clock       st   when   poll reach  delay  offset   disp
 ~172.12.14.1     .INIT.          16      –     64     0  0.000   0.000 16000.
 * sys.peer, # selected, + candidate, – outlyer, x falseticker, ~ configured
R4(config)#exit

Wooooah, too soon?

R4#sh ntp status
Clock is synchronized, stratum 2, reference is 172.12.14.1
nominal freq is 250.0000 Hz, actual freq is 250.0006 Hz, precision is 2**24
reference time is DCC9C244.9328C9C9 (19:13:08.574 UTC Fri May 19 2017)
clock offset is 5.0405 msec, root delay is 1.83 msec
root dispersion is 5.83 msec, peer dispersion is 0.05 msec
loopfilter state is ‘CTRL’ (Normal Controlled Loop), drift is -0.000002435 s/s
system poll interval is 64, last update was 25 sec ago.
R4#

Yup, too soon, took about 30 seconds or so to synchronize. Lets look at “sh ntp assoc”:

R4#sh ntp assoc

  address         ref clock       st   when   poll reach  delay  offset   disp
*~172.12.14.1     .LOCL.           1     27     64     7  1.839   5.040  1.678
 * sys.peer, # selected, + candidate, – outlyer, x falseticker, ~ configured
R4#

That is what we want to see, not just the asterisk, but the wavy line (whatever that is) along with the asterisk which indicates it is synched with Server. Also note it is 1 hop away from the Stratum 1 server, so the client is Stratum 2.

So to go through the fields in the “sh ntp assoc” I’ll do it bullet point style here:

• address = IP of the server this device is getting its time from
• ref clock = Where that server is getting its time from (LOCL means manually configured)
• st = Stratum of that server, in this case Stratum 1

Beyond that the fields are beyond the scope of CCNP and I don’t want to open that can of worms, but that is how to interpret those 3 fields.

Now I only have two routers so I cannot demonstrate this, but if there is a client one hop downstream from another client, they can share information with each other once the original client is synchronized with the Server.

You can simply type “ntp server 172.12.14.4” lets say if R5 was behind R4, and R4 would supply it time like a Server would.

Now for methods of Authentication or just NTP Server Protection, you can use Access-Lists to limit who can receive NTP from it, or configure Authentication

NTP Authentication uses MD5 Hash configured by Authentication Keys.

Multiple Keys can be configured for different peers, so you can configure a key per peer.

To configure this on the Server, this is how we do that in global configuration mode:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ntp authentication-key 1 md5 CCNP
R1(config)#ntp trusted-key 1
R1(config)#ntp authenticate
R1(config)#

The server will not start actually using authentication until you use the last command entered “ntp authenticate”.

Now on the client, the commands are exactly the same, with one additional command at the end:

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#ntp authentication-key 1 md5 CCNP
R4(config)#ntp trusted-key 1
R4(config)#ntp authenticate
R4(config)#ntp server 172.12.14.1 key 1
R4(config)#

And that is how it is done, that is all for now, later!

EDIT:

Had to cut that short due to company and actually enjoying my Friday, but back to it, and I wanted to first edit this with some output of what it looks like when Authentication is failing.

I wanted to demonstrate a couple of things after I stripped NTP completely off R4, and manually did a “clock set …” on it. I wanted to see if NTP will take precedence over a local manual configuration when you enable NTP, and also what the debug looks like when Authentication fails:

So first we strip the commands, reset the clock manually as it hangs onto its last known time even if you remove NTP (so it still had the same time as R1), so lets get to it quick:

Removal

R4(config)#do sh ntp assoc
R4(config)#do sh ntp stat
%NTP is not enabled.
R4(config)#do sh clock
.00:19:17.447 UTC Sun May 21 2017
R4(config)#exit

“clock set …” and “debug ntp events” started
R4#clock set 02:45:00 feb 27 2000
R4#
.Feb 27 02:45:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 00:20:05 UTC Sun May 21 2017 to 02:45:00 UTC Sun Feb 27 2000, configured from console by console.
R4#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

R4#debug ntp events
NTP events debugging is on

Giving it a try with just “ntp server …”

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#ntp server 172.12.14.1
R4(config)#
.Feb 27 02:55:41.571: %NTP : Drift Read : FFFFFFFF.FFFFD70D
.Feb 27 02:55:41.571: NTP: Initialized interface FastEthernet0/0
.Feb 27 02:55:41.571: NTP: Initialized interface FastEthernet0/1
.Feb 27 02:55:41.571: NTP: Initialized interface Loopback4
.Feb 27 02:55:41.571: NTP: Initialized interface VoIP-Null0

………… still waiting…
R4(config)#do sh ntp assoc

  address         ref clock       st   when   poll reach  delay  offset   disp
 ~172.12.14.1     .INIT.          16      –     64     0  0.000   0.000 16000.
 * sys.peer, # selected, + candidate, – outlyer, x falseticker, ~ configured
R4(config)#do sh ntp stat
Clock is unsynchronized, 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 (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.17 msec, peer dispersion is 0.00 msec
loopfilter state is ‘CTRL’ (Normal Controlled Loop), drift is -0.000002440 s/s
system poll interval is 64, never updated.

Getting impatient, time to “debug ntp all”
R4(config)#do debug ntp all
NTP events debugging is on
NTP core messages debugging is on
NTP clock adjustments debugging is on
NTP reference clocks debugging is on
NTP packets debugging is on
R4(config)#
May 21 00:32:41.241: NTP message sent to 172.12.14.1, from interface ‘FastEthernet0/1’ (172.12.14.4).
May 21 00:32:41.241: NTP message received from 172.12.14.1 on interface ‘FastEthernet0/1’ (172.12.14.4).
May 21 00:32:41.241: NTP Core(DEBUG): ntp_receive: message received
May 21 00:32:41.241: NTP Core(DEBUG): ntp_receive: peer is 0x67444C00, next action is 1.
May 21 00:32:41.241: NTP Core(DEBUG): receive: packet given to process_packet

Something finally happened, lets check out what!
R4(config)#do sh clock
00:33:12.941 UTC Sun May 21 2017
R4(config)#do sh ntp assoc

  address         ref clock       st   when   poll reach  delay  offset   disp
*~172.12.14.1     .LOCL.           1     46     64     3  1.929   0.140 3937.9
 * sys.peer, # selected, + candidate, – outlyer, x falseticker, ~ configured
R4(config)#

What???

I am guessing this is another bug I ran into last time I was NTP labbing, but in hopes that it isn’t I reloaded R4 t give it a chance.

Essentially the bug is that it will allow the commands to be entered for NTPv4, but Authentication is not doing anything between them, like its running NTPv3 (and I don’t see an “ntp …” option to set NTPv4.

So after the reload I re-manually set the clock, confirmed it retained the ntp server command, and did a debug all:

R4#sh clock
00:44:53.522 UTC Sun May 21 2017
R4#clock set 02:00:00 jan 15 2000
R4#
.Jan 15 02:00:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 00:45:23 UTC Sun May 21 2017 to 02:00:00 UTC Sat Jan 15 2000, configured from console by console.

R4#debug ntp all
NTP events debugging is on
NTP core messages debugging is on
NTP clock adjustments debugging is on
NTP reference clocks debugging is on
NTP packets debugging is on
R4#sh run | i ntp
ntp server 172.12.14.1
R4#
.Jan 15 02:00:39.051: NTP message sent to 172.12.14.1, from interface ‘FastEthernet0/1’ (172.12.14.4).
.Jan 15 02:00:39.051: NTP message received from 172.12.14.1 on interface ‘FastEthernet0/1’ (172.12.14.4).
.Jan 15 02:00:39.051: NTP Core(DEBUG): ntp_receive: message received
.Jan 15 02:00:39.051: NTP Core(DEBUG): ntp_receive: peer is 0x6743C8A0, next action is 1.
.Jan 15 02:00:39.051: NTP Core(DEBUG): receive: packet given to process_packet
.Jan 15 02:00:39.051: NTP Core(DEBUG): Peer becomes reachable, poll set to 6.

.Jan 15 02:00:39.051: NTP Core(INFO): peer 172.12.14.1 event ‘event_reach’ (0x84) status ‘unreach, conf, 3 events, event_reach’ (0x8034)
R4#
.Jan 15 02:00:39.051: NTP Core(INFO): synchronized to 172.12.14.1, stratum 1

Unbelievable, even with IOS code 15 I run into a bug.

Well that was my attempt to show more detail, just remember the commands AND DIFFERENCES between NTPv3 and NTPv4 for exam day 🙂