cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6359
Views
0
Helpful
12
Replies

CUCM v11 stratum number 5

sam saeed
Level 1
Level 1

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#

3 Accepted Solutions

Accepted Solutions

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.

View solution in original post

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.

View solution in original post

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.

View solution in original post

12 Replies 12

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

__________________________________________________
Please remember to rate useful posts clicking on the stars below.
LinkedIn Profile: do.linkedin.com/in/leosalcie

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        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:

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.

Cool, thanks. I just wanted to make sure since based on the docs it urged it fall between 1-3 stratum.

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.

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:

  • GPS/Atomic Clock
    • Stratum One Clock (1)
      • Stratum Two Clock (2)
        • CUCM Publisher (3)
          • CUCM Subscriber (4)
          • CUP Publisher/Subscribers (4)

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)

  • Cisco router (3)
    • CUCM Pub(4)

Are you pointing your pub directly to an external NTP source to get a lower stratum number? How secure is that?

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.

Great stuff Jonathan. I think this would be the way to deploy any cisco centric UC solution.

Please rate all useful posts

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.

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.

Thanks for the info. You are the beez knees my friend!

Many thx Jonathan for adding comments here. Very useful information which I was missing.

Keep it up mate

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: