02-12-2010 01:38 AM - edited 03-06-2019 09:41 AM
Hi All,
I have six switches , which I want to sync with a is acting as NTP server, how ever my two devices are able to sync with NTP server but rest four are not able to sync. the only command diffrence is "ntp clock-period ". wil it make any difference in synchronization. And i also do not know after how much time the devices sync with NTP server.
Regards and Thanks
Jagdev
Solved! Go to Solution.
02-12-2010 08:35 AM
I don't know how to do it on a Checkpoint, but somehow you need to fix it so it ties its NTP to the 10.40.0.4 or .5 interface.
Alternatively, in the client switch, do
ntp server 10.40.7.130
ntp server 10.40.7.131
And so on, ensuring that each switch uses an NTP server address in its own subnet.
Kevin Dorrell
Luxembourg
02-12-2010 01:47 AM
NTP clock-period
Can you post your NTP commands?
What is the result when you do "sh ntp status"?
02-12-2010 02:02 AM
Able to Sync
clock timezone GMT 0
clock summer-time BST recurring
ntp clock-period 17179251
ntp server 10.40.0.4
ntp server 10.40.0.5
sh ntp status
Clock is synchronized, stratum 2, reference is 10.40.0.4
nominal freq is 250.0000 Hz, actual freq is 250.0090 Hz, precision is 2**19
reference time is CF1FA225.1EFDBF6C (09:47:17.121 GMT Fri Feb 12 2010)
clock offset is -1.1660 msec, root delay is 6.13 msec
root dispersion is 111.89 msec, peer dispersion is 3.22 msec
Not Able to Sync
clock timezone GMT 0
clock summer-time BST recurring
ntp server 10.40.0.4
ntp server 10.40.0.5
sh ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 119.2092 Hz, actual freq is 119.2092 Hz, precision is 2**18
reference time is 00000000.00000000 (00:00:00.000 GMT Mon Jan 1 1900)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec
02-12-2010 05:02 AM
Can you ping the NTP servers from the unsynchronised switch?
Also, pay some attention to what source address the unsynchronised switch is using from its NTP ... does the NTP server have a valid route back to that address?
Finally, you could try a debug.
Kevin Dorrell
Luxembourg
02-12-2010 05:19 AM
Hello Kevin,
I see you are using a new account
Have you had problems with the old one?
It may be wise to send an email to Dan to solve this issue.
Best Regards
Giuseppe
02-12-2010 05:32 AM
Hi Giuseppe.
Thanks for pointing that out. Actually, I had been dormant for quite a while and I didn't realise I was on a different account. But now I see there are none of my old points next to my name. I'll talk to Dan about it.
With the old site, there was a problem that the user name was case sensitive. That is, if I logged in as Kevin.Dorrell, I would get a different set of points than if I logged in as kevin.dorrell, but they both referred back to the same cisco.com login.
Ciao,
Kevin
02-12-2010 05:50 AM
Hi Kevi,
Yes, I am able to ping 10.40.0.4 and 10.40.0.5.
Thanks and Regards
Jagdev
02-12-2010 06:22 AM
So, if you can ping the NTP servers from the unsynchronised switch then you have communication between them. Assuming you have no access-list restrictions on the NTP, the next thing I would do would be a debug ntp packets on the switch, not forgetting to do a term mon as well if necessary, and see if I can see the NTP packets in and out.
Kevin Dorrell
Luxembourg
02-12-2010 07:02 AM
The switchs which are able to sync do not show any out
put where as the switchs which are not able to sync show following out put:-
Swtich#
Feb 12 15:00:13: NTP: xmit packet to 10.40.0.5:
Feb 12 15:00:13: leap 3, mode 3, version 3, stratum 0, ppoll 64
Feb 12 15:00:13: rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
Feb 12 15:00:13: ref 00000000.00000000 (00:00:00.000 GMT Mon Jan 1 1900)
Feb 12 15:00:13: org 00000000.00000000 (00:00:00.000 GMT Mon Jan 1 1900)
Feb 12 15:00:13: rec 00000000.00000000 (00:00:00.000 GMT Mon Jan 1 1900)
Feb 12 15:00:13: xmt CF1FEB7D.F4B5CC78 (15:00:13.955 GMT Fri Feb 12 2010)
Feb 12 15:00:13: NTP: rcv packet from 10.40.7.131 to 10.40.7.254 on Vlan201:
Feb 12 15:00:13: leap 0, mode 4, version 3, stratum 1, ppoll 64
Swtich#
Feb 12 15:00:13: rtdel 0000 (0.000), rtdsp 02A0 (10.254), refid 4C434C00 (76.67.76.0)
Feb 12 15:00:13: ref CF1FEB2D.313B7000 (14:58:53.192 GMT Fri Feb 12 2010)
Feb 12 15:00:13: org CF1FEB7D.F4B5CC78 (15:00:13.955 GMT Fri Feb 12 2010)
Feb 12 15:00:13: rec CF1FEB42.E4F63000 (14:59:14.894 GMT Fri Feb 12 2010)
Feb 12 15:00:13: xmt CF1FEB42.E4F73000 (14:59:14.894 GMT Fri Feb 12 2010)
Feb 12 15:00:13: inp CF1FEB7D.F52A686E (15:00:13.957 GMT Fri Feb 12 2010)
Swtich#
Feb 12 15:00:15: NTP: xmit packet to 10.40.0.4:
Feb 12 15:00:15: leap 3, mode 3, version 3, stratum 0, ppoll 64
Feb 12 15:00:15: rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
Feb 12 15:00:15: ref 00000000.00000000 (00:00:00.000 GMT Mon Jan 1 1900)
Feb 12 15:00:15: org 00000000.00000000 (00:00:00.000 GMT Mon Jan 1 1900)
Feb 12 15:00:15: rec 00000000.00000000 (00:00:00.000 GMT Mon Jan 1 1900)
Feb 12 15:00:15: xmt CF1FEB7F.F5F20A94 (15:00:15.960 GMT Fri Feb 12 2010)
Feb 12 15:00:15: NTP: rcv packet from 10.40.7.130 to 10.40.7.254 on Vlan201:
Feb 12 15:00:15: leap 0, mode 4, version 3, stratum 1, ppoll 64
Swtich#
Feb 12 15:00:15: rtdel 0000 (0.000), rtdsp 02A3 (10.300), refid 4C434C00 (76.67.76.0)
Feb 12 15:00:15: ref CF1FEB2C.1A3B4000 (14:58:52.102 GMT Fri Feb 12 2010)
Feb 12 15:00:15: org CF1FEB7F.F5F20A94 (15:00:15.960 GMT Fri Feb 12 2010)
Feb 12 15:00:15: rec CF1FEB44.AF817000 (14:59:16.685 GMT Fri Feb 12 2010)
Feb 12 15:00:15: xmt CF1FEB44.AF826000 (14:59:16.685 GMT Fri Feb 12 2010)
Feb 12 15:00:15: inp CF1FEB7F.F6608AD4 (15:00:15.962 GMT Fri Feb 12 2010)
Swtich#
Thanks and regards
Jagdev
02-12-2010 07:39 AM
Is 10.40.7.254 and address of this switch? Does it have a presence in the 10.40.0.0 subnet? Maybe the switches that synchronize correctly have a presence in the 10.40.0.0 subnet, and those that don't have a presence on that subnet, don't synchronize. Is that so?
Is the NTP server actually a Cisco device as well? If so, maybe you need to nail down the address it uses to source its NTP packets with an ntp source <whatever>. At the moment it looks like it is sending its responses from a different IP from the one it received the query on.
Kevin Dorrell
Luxembourg
02-12-2010 08:21 AM
Yes, 10.40.7.254 is the address of the switch which is try to sync.
It does not have the presence on the 10.40.0.0 subnet the subnets are given below:-
10.40.0.0/25
10.40.7.254/25
the switch which are able to synchronize belong to the same subnet 10.40.0.0/25.
NTP server is a checkpoint firewall on Nokia platform.
from your observation i understand it receives request at 10.40.0.4 and responds back from 76.67.76.0,
is that so correct me if i am wrong?
Thanks and regards
Jagdev
02-12-2010 08:27 AM
Please also see the output of switch loggs which is able to sync:-
Feb 12 14:54:23: NTP: xmit packet to 10.40.0.5:
Feb 12 14:54:23: leap 0, mode 3, version 3, stratum 2, ppoll 1024
Feb 12 14:54:23: rtdel 004E (1.190), rtdsp 46E9 (276.993), refid 0A280004 (10.40.0.4)
Feb 12 14:54:23: ref CF1FE624.7D00A0E0 (14:37:24.488 GMT Fri Feb 12 2010)
Feb 12 14:54:23: org CF1FE61F.98184000 (14:37:19.594 GMT Fri Feb 12 2010)
Feb 12 14:54:23: rec CF1FE61F.7D230743 (14:37:19.488 GMT Fri Feb 12 2010)
Feb 12 14:54:23: xmt CF1FEA1F.734818AA (14:54:23.450 GMT Fri Feb 12 2010)
Feb 12 14:54:23: NTP: rcv packet from 10.40.0.5 to 10.40.0.2 on Vlan300:
Feb 12 14:54:23: leap 0, mode 4, version 3, stratum 1, ppoll 1024
Feb 12 14:54:23: rtdel 0000 (0.000), rtdsp 02B6 (10.590), refid 4C434C00 (76.67.76.0)
Feb 12 14:54:23: ref CF1FE9ED.30172000 (14:53:33.187 GMT Fri Feb 12 2010)
Feb 12 14:54:23: org CF1FEA1F.734818AA (14:54:23.450 GMT Fri Feb 12 2010)
Feb 12 14:54:23: rec CF1FEA1F.8ECCE000 (14:54:23.557 GMT Fri Feb 12 2010)
Feb 12 14:54:23: xmt CF1FEA1F.8ECE0000 (14:54:23.557 GMT Fri Feb 12 2010)
Feb 12 14:54:23: inp CF1FEA1F.742417BF (14:54:23.453 GMT Fri Feb 12 2010)
Feb 12 14:54:28: NTP: xmit packet to 10.40.0.4:
Feb 12 14:54:28: leap 0, mode 3, version 3, stratum 2, ppoll 1024
Feb 12 14:54:28: rtdel 004E (1.190), rtdsp 46E9 (276.993), refid 0A280004 (10.40.0.4)
Feb 12 14:54:28: ref CF1FE624.7D00A0E0 (14:37:24.488 GMT Fri Feb 12 2010)
Feb 12 14:54:28: org CF1FE624.61C00000 (14:37:24.381 GMT Fri Feb 12 2010)
Feb 12 14:54:28: rec CF1FE624.7D00A0E0 (14:37:24.488 GMT Fri Feb 12 2010)
Feb 12 14:54:28: xmt CF1FEA24.73413873 (14:54:28.450 GMT Fri Feb 12 2010)
Feb 12 14:54:28: NTP: rcv packet from 10.40.0.4 to 10.40.0.2 on Vlan300:
Feb 12 14:54:28: leap 0, mode 4, version 3, stratum 1, ppoll 1024
Feb 12 14:54:28: rtdel 0000 (0.000), rtdsp 02BB (10.666), refid 4C434C00 (76.67.76.0)
Feb 12 14:54:28: ref CF1FE9EC.197F3000 (14:53:32.099 GMT Fri Feb 12 2010)
Feb 12 14:54:28: org CF1FEA24.73413873 (14:54:28.450 GMT Fri Feb 12 2010)
Feb 12 14:54:28: rec CF1FEA24.58300000 (14:54:28.344 GMT Fri Feb 12 2010)
Feb 12 14:54:28: xmt CF1FEA24.58315000 (14:54:28.344 GMT Fri Feb 12 2010)
Feb 12 14:54:28: inp CF1FEA24.739C8245 (14:54:28.451 GMT Fri Feb 12 2010)
02-12-2010 08:35 AM
I don't know how to do it on a Checkpoint, but somehow you need to fix it so it ties its NTP to the 10.40.0.4 or .5 interface.
Alternatively, in the client switch, do
ntp server 10.40.7.130
ntp server 10.40.7.131
And so on, ensuring that each switch uses an NTP server address in its own subnet.
Kevin Dorrell
Luxembourg
02-12-2010 02:17 PM
If router A can successfully synchronize with an authoritative time source and router B can't, then why not let router B synchronize with A?
I know NTP sync is "cheap", network-speaking. But in my case, I am never a fan of having all appliance converge sync NTPs to the source. The edge-most appliance sync and the rest sync to this one.
02-12-2010 08:04 PM
NTP should be designed as a hierarchal tree where you have your authoratative time source hooked to say your core switches . Your distribution switches would then pick their time from those core switches . The access switches would then pick their time from the distr. layer boxes . This keeps from having to send ntp packets all the way across the network to sync their time, while ntp doesn't create a lot of traffic if you have a lot of switches there is no reason to add extra traffic where it is not needed .
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide