Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

NTP - insane issue

Hi,

We are migrating away from a router acting as a NTP Server to 2 X dedicated servers acting as NTP servers. To provide some resiliency, the solution is as follows:-

Server1 19.50.10.120> configured NTP Server 19.50.10.120 on the NTP Hub Router 10.80.100.3 and on the Spoke Router 10.80.100.3 as NTP Server. The Hub router is fine and is able to pick up the Clock from the HP Server but the spoke routers are failing. I can ping both the Server and the Hub router from the spoke. If I change the ip address on the spoke touter to the actual HP Server than my ntp status changes to synched.. Output below....

What am I doing wrong?

From Hub router:-

Hub_router#sh ntp associations

address ref clock st when poll reach delay offset disp

~127.127.7.1 127.127.7.1 7 53 64 377 0.0 0.00 0.0

*~19.50.10.120 192.168.171.36 3 39 64 377 1.3 -808.0 211.2

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

boi-mpls-hub-cabinteely#

Spoke_Router#sh ntp associations detail

10.80.100.3 configured, insane, invalid, stratum 4

ref ID 19.50.10.121, time CE05899C.3096F3AB (11:23:24.189 utc Mon Jul 13 2009)

our mode client, peer mode server, our poll intvl 1024, peer poll intvl 1024

root delay 40.25 msec, root disp 1650.62, reach 377, sync dist 1677.887

delay 5.07 msec, offset 1320.2882 msec, dispersion 3.31

precision 2**18, version 3

org time CE0589C8.42518693 (11:24:08.259 utc Mon Jul 13 2009)

rcv time CE0589C6.F0F929B2 (11:24:06.941 utc Mon Jul 13 2009)

xmt time CE0589C6.EFACA097 (11:24:06.936 utc Mon Jul 13 2009)

filtdelay = 5.07 5.08 5.10 4.73 4.78 5.04 4.91 4.71

filtoffset = 1320.29 1318.57 1316.83 1315.36 1313.20 1311.75 1309.98 1308.53

filterror = 0.02 0.03 0.05 0.06 0.08 0.09 0.11 0.12

Spoke_Router>sh ntp status

Clock is unsynchronized, stratum 16, no reference clock

nominal freq is 250.0000 Hz, actual freq is 249.9999 Hz, precision is 2**18

reference time is CE058457.F150DEF4 (11:00:55.942 utc Mon Jul 13 2009)

clock offset is -1.2188 msec, root delay is 47.03 msec

root dispersion is 188.00 msec, peer dispersion is 0.81 msec

Spoke_Router>sh ntp association

address ref clock st when poll reach delay offset disp

~10.80.100.3 19.50.10.120 4 39 1024 377 6.6 1477.2 9.6

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

oc-boieb-test-dmd-eu>

10 REPLIES
Bronze

Re: NTP - insane issue

Your hub-router seems only function as ntp-client, but not ntp-server.

so it won't respond to ntp requests from the spoke.

The hub may not operate as server because it's other configured ntp-server 127.127.7.1 does not respond correctly.

There may be a firewall in this path that does not allow ntp?

Pieter

Community Member

Re: NTP - insane issue

Peter

Definitely no Firewall along the path. I've enabled ntp debug on the spoke router and I am receiving ntp messages:-

!

On the hub router, output is now.

Hub_Router>sh ntp associations

address ref clock st when poll reach delay offset disp

*~19.50.10.120 192.168.171.36 3 59 64 377 1.4 -807.7 210.9

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

On the spoke

Spoke_Router>sh ntp associations

address ref clock st when poll reach delay offset disp

~10.80.100.3 19.50.10.120 4 234 1024 377 12.3 705.67 3.4

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

Spoke_Router>

.Jul 13 12:53:53.403 utc: NTP: rcv packet from 10.80.100.3 to 10.80.102.32 on Serial0/0/0:0.101:

.Jul 13 12:53:53.403 utc: leap 0, mode 4, version 3, stratum 4, ppoll 1024

.Jul 13 12:53:53.403 utc: rtdel 0AAD (41.702), rtdsp 29C7B (2611.252), refid 13320A78 (19.50.10.120)

.Jul 13 12:53:53.403 utc: ref CE059EC5.DFDFBDCE (12:53:41.874 utc Mon Jul 13 2009)

.Jul 13 12:53:53.403 utc: org CE059ED1.64532D3C (12:53:53.391 utc Mon Jul 13 2009)

.Jul 13 12:53:53.403 utc: rec CE059ED1.C68969FB (12:53:53.775 utc Mon Jul 13 2009)

.Jul 13 12:53:53.403 utc: xmt CE059ED1.C689E9B6 (12:53:53.775 utc Mon Jul 13 2009)

.Jul 13 12:53:53.403 utc: inp CE059ED1.67734BE0 (12:53:53.404 utc Mon Jul 13 2009)

.Jul 13 12:53:54.391 utc: NTP: xmit packet to 10.80.100.3:

.Jul 13 12:53:54.391 utc: leap 3, mode 3, version 3, stratum 0, ppoll 1024

.Jul 13 12:53:54.391 utc: rtdel 0CBF (49.789), rtdsp B58D (709.183), refid 13320A78 (19.50.10.120)

.Jul 13 12:53:54.391 utc: ref CE059D82.6684EBC6 (12:48:18.400 utc Mon Jul 13 2009)

.Jul 13 12:53:54.391 utc: org CE059ED1.C689E9B6 (12:53:53.775 utc Mon Jul 13 2009)

.Jul 13 12:53:54.391 utc: rec CE059ED1.67734BE0 (12:53:53.404 utc Mon Jul 13 2009)

.Jul 13 12:53:54.391 utc: xmt CE059ED2.64571A8D (12:53:54.391 utc Mon Jul 13 2009)

.Jul 13 12:53:54.403 utc: NTP: rcv packet from 10.80.100.3 to 10.80.102.32 on Serial0/0/0:0.101:

.Jul 13 12:53:54.403 utc: leap 0, mode 4, version 3, stratum 4, ppoll 1024

.Jul 13 12:53:54.403 utc: rtdel 0AAD (41.702), rtdsp 29C7B (2611.252), refid 13320A78 (19.50.10.120)

.Jul 13 12:53:54.403 utc: ref CE059EC5.DFDFBDCE (12:53:41.874 utc Mon Jul 13 2009)

.Jul 13 12:53:54.403 utc: org CE059ED2.64571A8D (12:53:54.391 utc Mon Jul 13 2009)

.Jul 13 12:53:54.403 utc: rec CE059ED2.C6E7E710 (12:53:54.776 utc Mon Jul 13 2009)

.Jul 13 12:53:54.403 utc: xmt CE059ED2.C6E870B9 (12:53:54.776 utc Mon Jul 13 2009)

.Jul 13 12:53:54.403 utc: inp CE059ED2.677C5851 (12:53:54.404 utc Mon Jul 13 2009)

.Jul 13 12:53:55.391 utc: NTP: xmit packet to 10.80.100.3:

.Jul 13 12:53:55.391 utc: leap 3, mode 3, version 3, stratum 0, ppoll 1024

.Jul 13 12:53:55.391 utc: rtdel 0CBF (49.789), rtdsp B58D (709.183), refid 13320A78 (19.50.10.120)

.Jul 13 12:53:55.391 utc: ref CE059D82.6684EBC6 (12:48:18.400 utc Mon Jul 13 2009)

.Jul 13 12:53:55.391 utc: org CE059ED2.C6E870B9 (12:53:54.776 utc Mon Jul 13 2009)

.Jul 13 12:53:55.391 utc: rec CE059ED2.677C5851 (12:53:54.404 utc Mon Jul 13 2009)

.Jul 13 12:53:55.391 utc: xmt CE059ED3.64539410 (12:53:55.391 utc Mon Jul 13 2009)

Running out of ideas??

Mary

Bronze

Re: NTP - insane issue

hub:

address ref clock st when poll reach delay offset disp

*~19.50.10.120 192.168.171.36 3 59 64 377 1.4 -807.7 210.9

spoke:

address ref clock st when poll reach delay offset disp

~10.80.100.3 19.50.10.120 4 234 1024 377 12.3 705.67 3.4

the hub's offset is -807.7 from it's reference clock, whereas the spoke's is 705.67 from the hub.

can be a timezone problem.

check timezone's on both routers and the server.

also check daylight saving setting.

what kind of routers are you using?

Community Member

Re: NTP - insane issue

Peter

The actual NTP Server is a Microsoft Server maintained by a 3rd party and the spoke router is a 2811.

Regards

Mary

Bronze

Re: NTP - insane issue

Hi Mary,

have you been able to chek this settins?

check timezone's on both routers and the server.

also check daylight saving setting

If the combination of current-time / Timezone / Daylight saving is not correct, then the time received from a ntp-server may be too different from the time on the ntp-client.

Like yjdabear allso sayd when time-difference is too large (more than 1 hour), they will not sync.

that's why i pointed out about the difference in offset.

don't be fooled by the messages logged both in UTC, this may be a hickup in the software, regcalculating UTC from clocktime corrected by timezone and daylight-saving.

try a "show clock" on both routers and a "date" on the unix server.

Community Member

Re: NTP - insane issue

Good idea Peter, and when I changed the Timezone to match the hubs, it did work but eventually it died again.

I have opened a tac call now as it is really confusing me....

oc-boieb-test-dmd-eu#sh run | include clock

clock timezone GMT 0

clock summer-time utc recurring last Sun Mar 1:00 last Sun Oct 1:00

churchstathlone_PE3_gwy>exit

[Connection to 10.80.102.195 closed by foreign host]

oc-boieb-test-dmd-eu#sh ntp ass

oc-boieb-test-dmd-eu#sh ntp associations

address ref clock st when poll reach delay offset disp

~10.80.100.4 19.50.10.121 4 23 64 177 5.1 1668.4 213.9

~10.80.100.3 19.50.10.120 4 23 64 177 6.6 1529.2 213.7

Blue

Re: NTP - insane issue

Does the Hub_router have any "ntp master #" and "ntp source-interface #/# (whichever 10.80.100.3 is)" configured?

The "sh run | inc ntp" from both routers will help.

Community Member

Re: NTP - insane issue

The Hub_router isn't the master, the Server is which I have since discovered is a Unix not MS server

Blue

Re: NTP - insane issue

Well, the Spoke_Router's "sh ntp associations detail" shows "root disp 1650.62", which causes the Cisco IOS NTP implementation to reject the association since it's in excess of 1000ms.

Community Member

Re: NTP - insane issue

Okay, I've opened up a TAC case because I now think its ios related.If I use another Hub router, different ios/hardware, it works fine. Thanks for you help.

1769
Views
0
Helpful
10
Replies
CreatePlease to create content