01-20-2016 07:43 AM - edited 03-17-2019 05:34 AM
Will it be an issue if the stratum number on PUB v11 is 5? I read in the docs that the stratum number on the pub needs to be either 1,2,3 and has to be be sourced from a linux box or Cisco IOS. On the pub the ntp server is configured as the CUBE router. I have the cube router as the NTP master (stratum number 4) which is sourcing the Ntp from the internet 0.north-america.pool.ntp.org (stratum number 3).
admin:utils ntp status
ntpd (pid 6090) is running...
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.10.10.1 12.200.151.18 4 u 61 64 377 0.475 -0.036 0.195
synchronised to NTP server (10.10.10.1) at stratum 5
time correct to within 87 ms
polling server every 64 s
CUBE#sh ntp status
Clock is synchronized, stratum 4, reference is 12.200.151.18
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**21
ntp uptime is 258390200 (1/100 of seconds), resolution is 4000
reference time is DA4A280E.ED67634F (10:36:46.927 EST Wed Jan 20 2016)
clock offset is 0.1442 msec, root delay is 37.92 msec
root dispersion is 52.25 msec, peer dispersion is 1.73 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000000014 s/s
system poll interval is 64, last update was 35 sec ago.
CUBE#sh ntp ass
address ref clock st when poll reach delay offset disp
~127.127.1.1 .LOCL. 7 3 16 377 0.000 0.000 0.232
*~12.200.151.18 198.72.72.10 3 38 64 377 30.204 0.144 1.732
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
CUBE#
CUBE#
Solved! Go to Solution.
01-20-2016 09:15 AM
Hi,
I am not sure about your deployment size and model. But this can be an issues only when you have high latency between ntp server and ntp source in your network combined with large deployments.
Unless you have an ntp issue, I don't think this is something you need to worry about.
01-20-2016 11:42 AM
In most environments I am in we choose two routers in the data center to act as time servers for the enterprise and give them DNS aliases (e.g. ntp1.cisco.com). Those two routers sync to an external stratum one server(s) and then peer with one another. To that I sync everything within the data center. WAN routers of other sites also sync to them while devices within each WAN site (e.g. switches) sync to that site's local WAN router. This is how I keep everything in stratum four or better.
If you have money to spend, the better option would be to have a real NTP server such as the ones Microsemi sells. No affiliation, just the company I see in the market. Even though their gear isn't that expensive most customers choose what I described in the first paragraph.
01-20-2016 12:57 PM
All of the pools are purely stratum two or lower servers. There is a separate list of stratum one servers I linked to above. Just be careful to select one that doesn't require notification and is open access.
01-20-2016 08:00 AM
Hi David,
Stratum level should be less than 4 on publisher for optimal performance.
http://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118718-technote-cucm-00.html
Regards
01-20-2016 08:56 AM
So should I hardcode the ntp stratum number in the cisco router to 2 and remove the ntp server of the us pool? I prefer to keep the router keeping updated from an external source since I found the time tends to drift on the router.
I tried another fqdn name from the same ntp pool and got a server with a better stratum number.
CUBE#
CUBE#show ntp stat
Clock is synchronized, stratum 3, reference is 107.170.224.8
nominal freq is 250.0000 Hz, actual freq is 249.9999 Hz, precision is 2**21
ntp uptime is 258843200 (1/100 of seconds), resolution is 4016
reference time is DA4A39D1.F8345DAE (11:52:33.969 EST Wed Jan 20 2016)
clock offset is 3.8473 msec, root delay is 99.54 msec
root dispersion is 66.54 msec, peer dispersion is 2.23 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000000106 s/s
system poll interval is 64, last update was 18 sec ago.
CUBE#
CUBE#
CUBE#show ntp ass
address ref clock st when poll reach delay offset disp
*~107.170.224.8 132.163.4.102 2 22 64 177 70.472 3.847 2.236
~127.127.1.1 .LOCL. 7 6 16 377 0.000 0.000 0.232
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
CUBE#
CUBE#
admin:utils ntp status
ntpd (pid 7550) is running...
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.10.10.1 107.170.224.8 3 u 6 64 1 0.586 -0.715 0.118
synchronised to NTP server (10.10.10.1) at stratum 4
time correct to within 1104 ms
polling server every 64 s
Current time in UTC is : Wed Jan 20 16:51:05 UTC 2016
Current time in America/New_York is : Wed Jan 20 11:51:05 EST 2016
admin:
01-20-2016 09:15 AM
Hi,
I am not sure about your deployment size and model. But this can be an issues only when you have high latency between ntp server and ntp source in your network combined with large deployments.
Unless you have an ntp issue, I don't think this is something you need to worry about.
01-20-2016 09:22 AM
Cool, thanks. I just wanted to make sure since based on the docs it urged it fall between 1-3 stratum.
01-20-2016 10:53 AM
I have to disagree with this advice, unfortunately. There is a CLI command: utils diagnose module ntp_stratum which is referenced in the TechNote that Leo linked to above. It should pass on all nodes including subscribers! If this fails TAC will tell you to fix it before supporting the system. I learned this the hard way when I had a CUPS (now IM&P) cluster randomly performing HA failovers even though the NTP time was definitely synced and stable across all nodes.
As I understand it, some components of the products will discard the NTP-synced time as unreliable based solely on the stratum number even if nothing is wrong. They claimed that if was working as designed and that I needed to get a more reliable I me source.
I suggest having the router sync to a stratum one or two time source or having CUCM and related apps sync farther up the tree in your environment. Faking the stratum isn't really a solution IMO.
01-20-2016 11:36 AM
Hey Johnathan,
Thanks for the reply. The router sync'd with a stratum 2 source as shown in my previous post. Which made the stratum on the router 3 and the stratum on cucm pub 4.
admin:utils diagnose module ntp_stratum
Log file: platform/log/diag1.log
Starting diagnostic test(s)
===========================
test - ntp_stratum : Passed
Diagnostics Completed
The final output will be in Log file: platform/log/diag1.log
Please use 'file view activelog platform/log/diag1.log' command to see the output
admin:
I googled the command you listed:
(utils diagnose module ntp_stratum) and came across a post that you were involved in 3 yrs ago and the hierarchy that you mentioned matches with the documentation I read:
If we draw this out it, the lowest you can go is this:
The router if I set it as NTP master sets a stratum of 7 or so. I'm syncing up with an external source us.ntp.pool which is coming in as a stratum 2 to the router.
Stratum Two Clock (2)
Are you pointing your pub directly to an external NTP source to get a lower stratum number? How secure is that?
01-20-2016 11:42 AM
In most environments I am in we choose two routers in the data center to act as time servers for the enterprise and give them DNS aliases (e.g. ntp1.cisco.com). Those two routers sync to an external stratum one server(s) and then peer with one another. To that I sync everything within the data center. WAN routers of other sites also sync to them while devices within each WAN site (e.g. switches) sync to that site's local WAN router. This is how I keep everything in stratum four or better.
If you have money to spend, the better option would be to have a real NTP server such as the ones Microsemi sells. No affiliation, just the company I see in the market. Even though their gear isn't that expensive most customers choose what I described in the first paragraph.
01-20-2016 12:15 PM
Great stuff Jonathan. I think this would be the way to deploy any cisco centric UC solution.
01-20-2016 12:41 PM
Cool, thanks for that insight! Do you use a private external ntp stratum 1 source or a public one? Because I'm sourcing from the us.ntp.pool and so far got the best stratum of 2 from external I may just have to cycle through all 4 fqdn entries to see if I get lucky and find a stratum 1 source.
01-20-2016 12:57 PM
All of the pools are purely stratum two or lower servers. There is a separate list of stratum one servers I linked to above. Just be careful to select one that doesn't require notification and is open access.
01-20-2016 01:36 PM
Thanks for the info. You are the beez knees my friend!
01-20-2016 07:09 PM
Many thx Jonathan for adding comments here. Very useful information which I was missing.
Keep it up mate
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