NTP 3750 not syncing

Jared McMillan · ‎11-02-2015

I have a 3750 running 12.2(25)SEE3 ipservices. NTP is not updating/syncing. Our NTP setup is for our sites to get their time from our core 6500s. We have many different models of 3750s running this same setup without issue. Trying to determine why this particular one is not sycning up.

Output from 3750 - All IPs are communciating and all IPs are in our core except the 128.109.16.122 IP. Our core is getting its time from that source. Tried entering it here to see if that would help, but not luck.

ntp clock-period 36029372
ntp server 10.2.66.2
ntp server 10.2.1.1
ntp server 128.109.16.122
ntp server 10.2.66.18 prefer - Added prefer to see if that would kick it in, no luck

SMA-METRO-3750#sh ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 119.2092 Hz, actual freq is 119.2073 Hz, precision is 2**18
reference time is D94FE0AC.EECC58F2 (15:25:32.932 EDT Tue Jul 14 2015)
clock offset is 0.1944 msec, root delay is 6.76 msec
root dispersion is 55.60 msec, peer dispersion is 0.64 msec
SMA-METRO-3750#sh ntp ass
SMA-METRO-3750#sh ntp associations

address ref clock st when poll reach delay offset disp
~10.2.66.2 0.0.0.0 16 - 64 0 0.0 0.00 16000.
~10.2.1.1 0.0.0.0 16 - 64 0 0.0 0.00 16000.
~128.109.16.122 0.0.0.0 16 - 64 0 0.0 0.00 16000.
~10.2.66.18 0.0.0.0 16 - 64 0 0.0 0.00 16000.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured

SMA-METRO-3750#sh ntp associations detail
10.2.66.2 configured, insane, invalid, unsynced, stratum 16
ref ID 0.0.0.0, time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
our mode client, peer mode unspec, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 0, sync dist 0.000
delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00
precision 2**5, version 3
org time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
rcv time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
xmt time D9E20018.DD139AD3 (10:30:32.863 EST Mon Nov 2 2015)
filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0

10.2.1.1 configured, insane, invalid, unsynced, stratum 16
ref ID 0.0.0.0, time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
our mode client, peer mode unspec, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 0, sync dist 0.000
delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00
precision 2**5, version 3
org time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
rcv time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
xmt time D9E1FFE8.DC767E7A (10:29:44.861 EST Mon Nov 2 2015)
filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0

128.109.16.122 configured, insane, invalid, unsynced, stratum 16
ref ID 0.0.0.0, time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
our mode client, peer mode unspec, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 0, sync dist 0.000
delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00
precision 2**5, version 3
org time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
rcv time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
xmt time D9E1FFF4.DD891758 (10:29:56.865 EST Mon Nov 2 2015)
filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0

10.2.66.18 configured, insane, invalid, unsynced, stratum 16
ref ID 0.0.0.0, time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
our mode client, peer mode unspec, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 0, sync dist 0.000
delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00
precision 2**5, version 3
org time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
rcv time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
xmt time D9E20019.DEDEF8B7 (10:30:33.870 EST Mon Nov 2 2015)
filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0

Ganesh Hariharan · ‎11-02-2015

Hi Jared,

Output for show ntp association shows insane that means devices basic sanity check for incoming NTP packet which is getting failed.

Just Try the below commands

I belive NTP servers are all reacble from this client and issue show ntp status on the ntp server to check the syn status of the clock.If NTP server is not syn itself try to disable and re-enable the NTP configuration. I dont see any MD5 authentication is happening between NTP packets.

Also Reach counter is 0 that mean no NTP packets has ever reached, so try debug NTP packet on device to see what is happening when NTP is enabled.

Hope it Helps..

-GI

Rate Helpful Posts

Mark Malone · ‎11-02-2015

Also make sure you can ping the ntp server and make sure no acl is blocking port 123 tcp/udp

Not ideal but quick way to get ntp to sync sometimes is reboot the switch oince reachbility is there , running a constant ping to the server from the source device can help as well

that ntp clock period is from that switch it should not be copied over from another switch its generated locally per device

Jared McMillan · ‎11-02-2015

Each IP is able to be pinged. And there is no ACL blocking port 123 tcp/udp. We 129 other sites running the same setup without issues as far as i know. Will reboot this switch after hours.

The NTP clock period may have gotten copied over from another switch config. Can i blow away ntp clock period and re-enter the command? Not sure if that would help.

thank you for the responses.

Mark Malone · ‎11-02-2015

the clock period is generated by local router/switch so shouldnt be copied over and should be removed if it was , the switch will generate a new 1 , i dont see it stopping a sync though

ntp clock-period

---------------------------
Caution Do not enter this command; it is documented for informational purposes only. The system automatically generates this command as Network Time Protocol (NTP) determines the clock error and compensates.

--------------------------------------------------------------------------------

As NTP compensates for the error in the software clock, it keeps track of the correction factor for this error. When the value for the clock period needs to be adjusted, the system automatically enters the correct value into the running configuration. To remove the automatically generated value for the clock period, use the no form of this command.

Mark Malone · ‎11-02-2015

couple of things to try as well

-manually set the clock for now , when the router knows the right time it can sync quicker (if the clock is too far off it may not sync)

-set an ntp source interface on the switch ntp source interface vlan 1

Jared McMillan · ‎11-02-2015

The clock is correct and not off at all.

SMA-METRO-3750#sh clock
.12:33:53.157 EST Mon Nov 2 2015

Here is the core's clock,

EUG-METRO-6506-1#sh clock
12:34:48.991 EST Mon Nov 2 2015

Have these current settings for NTP

ntp clock-period 36029372
ntp source Vlan1
ntp server 10.2.66.2
ntp server 10.2.1.1
ntp server 128.109.16.122
ntp server 10.2.66.18 prefer

Mark Malone · ‎11-02-2015

you could be hitting a bug , i would remove the clock period do the reload if its still not syncing after that you could check the release guide for that ios and see if there is any known ntp caveats for that version, even though other switches on same ios may not be effected you could have hit the trigger for it on just that switch.