NTP authentication

This is scenario 3 dealing with NTP and in this post I will set up NTP authentication. Remember that the purpose is for the client to authenticate the server. First will make sure NTP is synchronized on the client. Next, we will turn on authentication on the client only until the clocks become unsynchronized. Finally, we will configure the server with the appropriate key and make sure the client is synchronized again.

We use the same topology as the other NTP scenarios:
R4, R5 and R6 connected via full mesh frame-relay on subnet 172.12.45.0/24

Let's make sure R6, the master, is synchronized first:

R6#show clock
20:14:37.215 MDT Mon Jun 2 2008

R6#show ntp status | inc Clock is
Clock is synchronized, stratum 2, reference is 127.127.7.1

R4:

R4#show ntp status | in Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

and R5:

R5#show ntp status | inc Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

Let's configure authentication on R4:

R4(config)#ntp authenticate
R4(config)#ntp authentication-key 1 md5 cisco
R4(config)#ntp trusted-key 1
R4(config)#ntp server 172.12.45.6 key 1

R4#debug ntp validity
NTP peer validity debugging is on
R4#debug ntp authentication
NTP authentication debugging is on

In a few moments we get these debug messages:

R4(config)#
Jun 3 03:24:49.759: NTP: packet from 172.12.45.6 failed validity tests 10
Jun 3 03:24:49.763: Authentication failed
R4(config)#

What's strange is that R4 is still synchronized with R6:

R4#show ntp status
Clock is synchronized, stratum 3, reference is 172.12.45.6

So I waited about 10 minutes (it seemed that long) and now R4 is unsynchronized:

R4#show ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock

Now let's configure NTP authentication on R6:

R6(config)#ntp authenticate
R6(config)#ntp authentication-key 1 md5 cisco

On R4 I will set up some debugging, a lot of the output doesn't make much sense, but here it is:

R4#debug ntp packets
NTP packets debugging is on

!! HERE R4 TRANSMITS A PACKET WITH AUTHENTICATION-KEY 1

.Jun 3 03:36:10.711: NTP: xmit packet to 172.12.45.6:
.Jun 3 03:36:10.715: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Jun 3 03:36:10.715: rtdel 0D4E (51.971), rtdsp 05CD (22.659), refid AC0C2D06 (172.12.45.6)
.Jun 3 03:36:10.719: ref CBEF37C1.C8A9606E (20:23:45.783 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.719: org CBEF3A6A.BF8D3204 (20:35:06.748 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.723: rec CBEF3A6A.C784D317 (20:35:06.779 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.723: xmt CBEF3AAA.B614DB93 (20:36:10.711 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.727: Authentication key 1

!! HERE R4 RECEIVES A PACKET WITH AUTHENTICATION-KEY 1

.Jun 3 03:36:10.771: NTP: rcv packet from 172.12.45.6 to 172.12.34.4 on FastEthernet0/1:
.Jun 3 03:36:10.775: leap 0, mode 4, version 3, stratum 2, ppoll 64
.Jun 3 03:36:10.779: rtdel 0000 (0.000), rtdsp 0002 (0.031), refid 7F7F0701 (127.127.7.1)
.Jun 3 03:36:10.779: ref CBEF3A89.50E1C8AB (20:35:37.315 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.783: org CBEF3AAA.B614DB93 (20:36:10.711 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.783: rec CBEF3AAA.C3941C78 (20:36:10.763 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.787: xmt CBEF3AAA.C39DD400 (20:36:10.764 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.791: inp CBEF3AAA.C565D38F (20:36:10.771 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.791: Authentication key 1

R4 is now synchronized:

R4#show ntp status
Clock is synchronized, stratum 3, reference is 172.12.45.6
nominal freq is 250.0000 Hz, actual freq is 250.0004 Hz, precision is 2**18
reference time is CBEF3AAA.C565D38F (20:36:10.771 MDT Mon Jun 2 2008)
clock offset is 22.8825 msec, root delay is 59.68 msec
root dispersion is 15897.92 msec, peer dispersion is 15875.02 msec

Let's check R5 to see if it is still synchronized:

R5#show ntp status | inc Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

As you can see, R5 is still synchronized because it is not requesting authentication from R6. R4 on the other sends the request with an authentication key and requires that the time-source, R6, does so as well.

Well, this lab went okay. I have had many problems with ntp authentication before. Initially, I thought I would have problems again when R4 was not un-synchronizing with R6 when we first set up a key on R4. Well, it took a few minutes, so I guess patience is this key. You can't afford to be too patient though, you only have 8 hours on lab day :)