cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
472
Views
0
Helpful
1
Replies
NormMuelleman
Beginner

NTP synch issues

Hello all

Having an issue with NTP at my new location. Bit of background:

Access A  Access B    Distro       Core

______     ______     ______     ______

|          |    |          |    |          |   |          |

|          |----|          |----|          |---|          |

|______|    |_____|    |______|   |______|       

So, there is an NTP server hanging off the core. No firewall exists between the NTP server and the core (it's within the LAN)

All devices above had the same NTP statements.

All devices can ping the NTP server

Access B, Distro, and Core show that NTP is working. They have associations, the clocks are synched, etc.

Access A is NOT synched.

I've gone line by line thru the NTP configs; they are identical on all switches (IP addresses changed):

ntp logging

ntp authentication-key 1 md5 happyday

ntp authenticate

ntp trusted-key 1

ntp clock-period 36029132 (these vary with device)

ntp source Vlan150

ntp access-group peer 30

ntp access-group serve-only 31

ntp server 10.1.0.1 key 1

ntp server 10.1.15.1

ntp server 10.2.50.100 key 1 prefer

I turned on all debuging for NTP. I can see that accessA is sending packets to the three time devices. I can see that the devices are sending NTP packets with the correct times and timezone back to AccessA. But AccessA is NOT associating:

AccessA#sho ntp ass

      address         ref clock     st  when  poll reach  delay  offset    disp

~10.1.0.1         0.0.0.0          16     -    64    0     0.0    0.00  16000.

~10.1.15.1        0.0.0.0          16     -    64    0     0.0    0.00  16000.

~10.2.50.100      0.0.0.0          16     -    64    0     0.0    0.00  16000.

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

I've tried to completely remove the NTP configs from the switch, and put them back in. No change.

I've tried to change the PREFER statement from 10.2.50.100 to 10.1.0.1...and back again..no change.

Like I said, all the other switches are having no issues. I even removed the accesslist for the management vlan just to ensure it was not blocking anything, and no change. Here is a sample of the debug output (ip's changed) Also note the *** in the xmit packets...

121708: .May 26 23:00:59.597 KBL: NTP: xmit packet to 10.1.0.1:

121709: .May 26 23:00:59.597 KBL:  leap 3, mode 3, version 3, stratum 0, ppoll 64

121710: .May 26 23:00:59.597 KBL:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)

121711: .May 26 23:00:59.597 KBL:  ref 00000000.00000000 (04:30:00.000 KBL Mon Jan 1 1900)***

121712: .May 26 23:00:59.597 KBL:  org 00000000.00000000 (04:30:00.000 KBL Mon Jan 1 1900)***

121713: .May 26 23:00:59.597 KBL:  rec 00000000.00000000 (04:30:00.000 KBL Mon Jan 1 1900)***

121714: .May 26 23:00:59.597 KBL:  xmt D54CD363.99185907 (23:00:59.598 KBL Sun May 26 2013)

121715: .May 26 23:00:59.597 KBL:  Authentication key 1

121716: .May 26 23:00:59.597 KBL: NTP: xmit packet to 10.2.50.100:

121717: .May 26 23:00:59.597 KBL:  leap 3, mode 3, version 3, stratum 0, ppoll 64

121718: .May 26 23:00:59.597 KBL:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)

121719: .May 26 23:00:59.597 KBL:  ref 00000000.00000000 (04:30:00.000 KBL Mon Jan 1 1900)***

121720: .May 26 23:00:59.597 KBL:  org 00000000.00000000 (04:30:00.000 KBL Mon Jan 1 1900)***

121721: .May 26 23:00:59.597 KBL:  rec 00000000.00000000 (04:30:00.000 KBL Mon Jan 1 1900)***

121722: .May 26 23:00:59.597 KBL:  xmt D54CD363.9976DD46 (23:00:59.599 KBL Sun May 26 2013)

121723: .May 26 23:00:59.597 KBL:  Authentication key 1

121724: .May 26 23:00:59.597 KBL: NTP: rcv packet from 10.1.0.1 to 10.1.15.17 on VlanXXX:

121725: .May 26 23:00:59.597 KBL:  leap 0, mode 4, version 3, stratum 2, ppoll 64

121726: .May 26 23:00:59.597 KBL:  rtdel 0050 (1.221), rtdsp 02A6 (10.345), refid D62D81AE (10.2.50.100)

121727: .May 26 23:00:59.597 KBL:  ref D54CD087.C41E4772 (22:48:47.766 KBL Sun May 26 2013)

121728: .May 26 23:00:59.597 KBL:  org D54CD363.99185907 (23:00:59.598 KBL Sun May 26 2013)

121729: .May 26 23:00:59.597 KBL:  rec D54CD384.9A245D48 (23:01:32.602 KBL Sun May 26 2013)

121730: .May 26 23:00:59.597 KBL:  xmt D54CD384.9A2EF734 (23:01:32.602 KBL Sun May 26 2013)

121731: .May 26 23:00:59.597 KBL:  inp D54CD363.99F9E10C (23:00:59.601 KBL Sun May 26 2013)

121732: .May 26 23:00:59.597 KBL: NTP: rcv packet from 10.2.50.100 to 10.1.15.17 on Vlanxxx:

121733: .May 26 23:00:59.597 KBL:  leap 0, mode 4, version 3, stratum 1, ppoll 64

121734: .May 26 23:00:59.597 KBL:  rtdel 0000 (0.000), rtdsp 0012 (0.275), refid 464C5900 (70.76.89.0)

121735: .May 26 23:00:59.597 KBL:  ref D54CD382.48C4F81B (23:01:30.284 KBL Sun May 26 2013)

121736: .May 26 23:00:59.597 KBL:  org D54CD363.9976DD46 (23:00:59.599 KBL Sun May 26 2013)

121737: .May 26 23:00:59.597 KBL:  rec D54CD384.9A828552 (23:01:32.603 KBL Sun May 26 2013)

N-LNK-DASCB-ASW-3750#

121738: .May 26 23:00:59.597 KBL:  xmt D54CD384.9A887AEC (23:01:32.603 KBL Sun May 26 2013)

121739: .May 26 23:00:59.597 KBL:  inp D54CD363.9A68E2E3 (23:00:59.603 KBL Sun May 26 2013)

As you can see, AccessA is sending packets to the timeserver devices. I MANUALLY set the date/time on AccessA. It is correct with the rest of the network. But you can see AccessA in the statements with the *** at the end is sending incorrect date/time info out. BUT, the time servers are sending back the correct date/time timezone info. And there are NO authentication errors.

Several of us are at a quandry on what's up. Any thoughts?

1 REPLY 1
Leo L
VIP Community Legend

Duplicate posts.