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

NTP problem

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

1 ACCEPTED SOLUTION

Accepted Solutions

Re: NTP problem

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

14 REPLIES
Hall of Fame Super Blue

Re: NTP problem

NTP clock-period is an appliance generated command when you enable NTP on the appliance.  This does NOT affect the NTP synchronization of your appliance to the NTP source.

Can you post your NTP commands?
What is the result when you do "sh ntp status"?

Community Member

Re: NTP problem

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

Re: NTP problem

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

Hall of Fame Super Silver

Re: NTP problem

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

Re: NTP problem

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

Community Member

Re: NTP problem

Hi Kevi,

Yes, I am able to ping 10.40.0.4 and 10.40.0.5.

Thanks and Regards

Jagdev

Re: NTP problem

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

Community Member

Re: NTP problem

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

Re: NTP problem

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

Community Member

Re: NTP problem

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

Community Member

Re: NTP problem

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)

Re: NTP problem

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

Hall of Fame Super Blue

Re: NTP problem

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.

Purple

Re: NTP problem

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 .

796
Views
0
Helpful
14
Replies
CreatePlease to create content