2

We have a Cisco ISE 2.0 in our lab doing some 802.1X testing. To have synchonized times, we use an NTP server in the same subnet as the ISE to sync all the components (stratum 3, based on Bluecat appliances). All switches, firewalls and other components use it as timezone and it works.

I configured the same NTP server on my Cisco ISE, but even after multiple restarts it does not use it as NTP source.

ise/admin# sh run | i ntp
ntp server 146.140.66.230
ntp server 62.75.254.179

ise/admin# sh run | i timezone
clock timezone CET

ise/admin# sh ntp
Configured NTP Servers:
  146.140.66.230
  62.75.254.179

synchronised to local net at stratum 11
   time correct to within 11 ms
   polling server every 64 s

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*127.127.1.0     .LOCL.          10 l   16   64  377    0.000    0.000   0.000
 146.140.66.230  192.76.247.100   3 u   51   64  377    0.221  134683. 21473.0
 62.75.254.179   5.100.133.221    2 u   41   64  377    3.941  142841. 14340.1

* Current time source, + Candidate , x False ticker

Warning: Output results may conflict during periods of changing synchronization.

Both of them are reachable (the first one even in the same subnet), as can be also seen at the delay / jitter values. Interestingly the offset differs quite significant looking at both time servers. The offset however is roughly correct, slightly more than 2 minutes. As I do not have access to the root shell, I cannot use ntpq as indicated by this tech note. Additionally, as far as I know, none of both sersers is a Microsoft NTP.

Update1

Just to make sure it is not an NTP server issue, I configured one of our Cisco routers as NTP server, which itself uses 146.140.66.230. ISE recognizes it as stratum 4 server, but does not choose it as time source.

Any hints how to tackle this one?

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 15 '17 at 1:20
  • @RonMaupin thank you for the reminder. Unfortunatly, neither rebooting the box as suggested below did help, nor did we find a solution. – waza-ari Aug 15 '17 at 6:23
1

NTP is choosing to use the local time source because it has deemed it "better" (or more trustworthy) than the other sources you have configured. The stratum is only one piece of information NTP will use in determining it's source.

In your case, the other two servers have significantly (in NTP's view) different times the the currently set time and the jitter value for those two servers is extreme to say the least. Based on this information, NTP is choosing to continue using the local time source over the servers you have configured.

First, set up your own time server (or servers) on the local network and configure it to synchronize with reliable time sources (don't use ntp pool servers). For instance, Hurricane Electric maintains several NTP servers for public use. While they do offer three, I advise you find reliable sources from multiple organizations. This is fairly easy using a Linux platform or you can use your router as you mentioned (although this will put more load on your router).

Now, configure ISE and other devices to synchronize with your local time source. As long as your local time sources have no issues getting to it's sources, this time should get chosen over the local clock.

| improve this answer | |
0

Had a similar problem with sh ntp status using local even after using application stop ise then application start ise for a few days. We decided to try reload, and after the ISE box booted up, it picked a good network time source and has been holding that time correctly ever since.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.