Clock not syncing with NTP server

Answered Question
Jul 16th, 2008
User Badges:

I am having issues with 3600 and 7200 routers not sysncing with NTP server. My NTP server is working fine as I have other devices syncing to it. The 3600 and 7200 routers can sync to public NTP servers on the internet but cannot sync to my internal NTP server. The routers do have access to the NTP server because they and ping and traceroute to it.

Correct Answer by Richard Burts about 8 years 9 months ago

Mike


If you can ping the NTP server address sourcing the ping from FastEther2/0 then that does demonstrate IP connectivity, which is one of the first things I would look at. So that is good.


Based on the information so far I am suspicious about the firewall(s) and whether they are blocking some NTP traffic. I had a situation at a customer site once where their firewall was permitting only if both source port and destination port were NTP. There was a device sending NTP requests but the source port was some high port - and was being blocked even though it was a very legitimate NTP request. Could something like that be going on that does permit NTP from some devices but not from others?


HTH


Rick

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
paolo bevilacqua Wed, 07/16/2008 - 13:03
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Hi, IOS is very picky about NTP and as soon something doesn't seem right, it won't synch.


Eg, server claims to be stratum 0, or other apparently minor inconsistencies.

mjhagen Wed, 07/16/2008 - 13:10
User Badges:

NTP server is running on a Linux machine.


NTP Status from router not working:


Clock is unsynchronized, stratum 16, no reference clock

nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24

reference time is CC28B5C4.FD1E3E38 (11:00:36.988 PST Wed Jul 16 2008)

clock offset is -7.0256 msec, root delay is 168.08 msec

root dispersion is 71.73 msec, peer dispersion is 0.47 msec


NTP Status from different router.

Clock is synchronized, stratum 4, reference is 172.17.2.166

nominal freq is 249.5901 Hz, actual freq is 249.5873 Hz, precision is 2**18

reference time is CC28E17F.B5C3C30C (14:07:11.710 PST Wed Jul 16 2008)

clock offset is -0.1556 msec, root delay is 8.09 msec

root dispersion is 32.78 msec, peer dispersion is 0.03 msec

paolo bevilacqua Wed, 07/16/2008 - 13:13
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Do you have nat or fw between routers and ntp ?

mjhagen Wed, 07/16/2008 - 13:16
User Badges:

Yes firewall is in front of NTP server. I have allowed anything over NTP to it as I have some switches and other firewall accessing it.

sundar.palaniappan Wed, 07/16/2008 - 14:04
User Badges:
  • Green, 3000 points or more

Are you doing NTP authentication. If you are then make sure the key configured is correct. Another thing to check is if you are using a different source address for NTP peering then make sure you can ping the NTP server from the sourced IP. NTP is somewhat flaky and I have had some situations where I had to reload the box to make NTP sync as there's no clear command to try and force it to sync up.


HTH


Sundar

Richard Burts Wed, 07/16/2008 - 18:58
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Mike


We might be in a better position to answer your issue if we had more details about your environment. Perhaps you could post the output of show run | include ntp

Also it might be help if you would post the output of show ntp association detail


HTH


Rick

mjhagen Thu, 07/17/2008 - 07:57
User Badges:

Some information on the environment.

3640 ISP router

(cannot connect to NTP)

|

2912 Switch connected to router

(cannot connect to NTP server)

|

Two Juniper Firewall Connected to Switch

(can connect to NTP server)

|

4500 Switch Connected to firewalls

(can connect to NTP server)


Show NTP config of 3640:

ntp source FastEthernet2/0

ntp server 69.25.233.209


Sh ntp associayion:

address ref clock st when poll reach delay offset disp

~69.25.233.209 0.0.0.0 16 - 64 0 0.0 0.00 16000.

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

mjhagen Thu, 07/17/2008 - 07:50
User Badges:

I am not using any Authentication. I am sourcing the ip address of interface and I am able to ping the NTP server from that address.



Correct Answer
Richard Burts Thu, 07/17/2008 - 08:09
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Mike


If you can ping the NTP server address sourcing the ping from FastEther2/0 then that does demonstrate IP connectivity, which is one of the first things I would look at. So that is good.


Based on the information so far I am suspicious about the firewall(s) and whether they are blocking some NTP traffic. I had a situation at a customer site once where their firewall was permitting only if both source port and destination port were NTP. There was a device sending NTP requests but the source port was some high port - and was being blocked even though it was a very legitimate NTP request. Could something like that be going on that does permit NTP from some devices but not from others?


HTH


Rick

mjhagen Thu, 07/17/2008 - 08:18
User Badges:

I was originally allowing the access list in the firewall as:

permit udp any gt 1023 host 69.25.233.209 eq ntp


I changed it to:

permit udp any host 69.25.233.209 eq ntp


That solved the problem thanks



Richard Burts Thu, 07/17/2008 - 08:56
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Mike


I am glad that my suggestion helped you solve your problem. Thank you for using the rating system to indicate that your problem was solved (and thanks for the rating). It makes the forum more useful when people can read about about a problem and can know that a suggestion did lead to a solution.


HTH


Rick

Actions

This Discussion