4

I have three Cisco routers connected as shown in the diagram.

enter image description here

The problem is, while R1 is synchronizing the clock using NTP, R2 and R3 are not.

All the three routers have been configured for NTP using the same set of commands,

ntp server 192.168.10.2
ntp authenticate
ntp authentication-key 1 md5 <key>
ntp trusted-key 1
ntp update-calendar

R1 synchronized perfectly. But R2 and R3 did not.

For R2 and R3 the debugging commands show output like this,

R2#show ntp status
Clock is insane, stratum 16, reference is 192.168.10.2 nominal freq is 000.0000 Hz, actual freq is 000.0000 Hz, precision is 0**00 reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1990) clock offset is 0.00 msec, root delay is 0.00 msec root dispersion is 0.00 msec, peer dispersion is 0.00 msec.

Turning debug ntp on shows this,

Mar 01 00:25:10.243: NTP: xmit packet to 192.168.10.2
Mar 01 00:25:10.254: NTP: rcv packet from 192.168.10.2
Mar 01 00:30:10.244: NTP: xmit packet to 192.168.10.2
Mar 01 00:30:10.271: NTP: rcv packet from 192.168.10.2

So, the NTP packet are being transmitted all right.

Any suggestion will be appreciated.

Masroor
  • 183
  • 1
  • 9
  • 1
    Found the bug, the actual command at the routers should have been `ntp server 192.168.10.2 key 1`. I did not assign key value, and the routers were using the default 0. But why did R1 synchronize? – Masroor Mar 15 '13 at 04:21
  • 1
    Different code version perhaps? – Shane Madden Mar 15 '13 at 06:18
  • @ShaneMadden Perhaps not, all three routers are exactly identical, running the same IOS. – Masroor Mar 15 '13 at 06:31
  • @MMA Please post that comment as an Answer and Accept it when you have the chance. Thank you. – Chris S Mar 15 '13 at 17:21

1 Answers1

3

The mistake in this case was, not properly specifying the key. Running show running-config on the routers showed an output like this,

--truncated--
ntp server 192.168.10.2 key 0
--truncated--

where the actual key in question was 1. Further investigation of the ntp server command shows us that this command has a number of optional parameters including [key key-id]. When the user forgets to specify a key value, the router assigns a default value of zero. Thus this causes all the NTP packets to become untrusted and getting rejected. Eventually, the time remains unsynchronized and the NTP client shows an insane condition.

Simply specifying the key value in the following manner solved the problem.

ntp server 192.168.10.2 key 1

Perhaps the reason initially R1 did synchronize the time was that its NTP commands were issued first after which the key value in the NTP server was configured. The NTP server was already running an NTP service with a default key value of 0, where, later on, this symmetric shared secret was set to the desired different value of 1.

Masroor
  • 183
  • 1
  • 9