cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
362
Views
5
Helpful
5
Replies
niuoras01
Beginner

Cisco 7821 excessive NTP requests

Hello,

 

I have a 7821 phone running the latest multiplatform (MPP) firmware, 11.2.3 MSR1-1.  I've noticed that the phone sends an NTP request to my local NTP server (configured via DHCP) every 64 seconds.  Is this normal behavior?  It seems a bit excessive to me - I would expect once per hour or something like that.  The phone works normally, I'm just wondering about the NTP traffic.

 

I've included the tcpdump trace for one NTP transaction, which repeats every 64 seconds as noted above (phone and NTP server IP addresses have been redacted):

 

10:42:23.272164 IP (tos 0x0, ttl 64, id 41618, offset 0, flags [none], proto UDP (17), length 76)
    cp-7821.51885 > ntp-server.ntp: [udp sum ok] NTPv4, length 48
        Client, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 6 (64s), precision 0
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3781870943.251586999 (2019/11/04 10:42:23)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3781870943.251586999 (2019/11/04 10:42:23)
10:42:23.273026 IP (tos 0xb8, ttl 64, id 17285, offset 0, flags [DF], proto UDP (17), length 76)
    ntp-server.ntp > cp-7821.51885: [udp sum ok] NTPv4, length 48
        Server, Leap indicator:  (0), Stratum 3 (secondary reference), poll 6 (64s), precision -13
        Root Delay: 0.082794, Root dispersion: 0.053054, Reference-ID: dc1-ntp02.bellmtsdatacentres.com
          Reference Timestamp:  3781870496.148969410 (2019/11/04 10:34:56)
          Originator Timestamp: 3781870943.251586999 (2019/11/04 10:42:23)
          Receive Timestamp:    3781870943.272210648 (2019/11/04 10:42:23)
          Transmit Timestamp:   3781870943.272820094 (2019/11/04 10:42:23)
            Originator - Receive Timestamp:  +0.020623649
            Originator - Transmit Timestamp: +0.021233094

Thanks!

5 REPLIES 5
bijpraka
Cisco Employee

Is there a frequent change in time from the ntp server? The synch should happen once every hour.


@bijpraka wrote:

Is there a frequent change in time from the ntp server? The synch should happen once every hour.


Not as far as I can tell.  However, my NTP server gets its upstream time from pool.ntp.org rather than a local time source so perhaps the jitter is higher than the Cisco phone would like to see, I don't know.  None of my other NTP devices seem to have a problem with it.

You can raise a case with TAC for this to be looked into. The design is to query once an hour. It should maintain that unless there is a major difference in time.


@bijpraka wrote:

You can raise a case with TAC for this to be looked into. The design is to query once an hour. It should maintain that unless there is a major difference in time.


Thanks, but unfortunately I don't have a Cisco support contract.  I'm just using this phone privately in a home setting.

joelm
Beginner

NTP will automatically vary its polling time based on how well your device is doing relative to the time source(s).  The polling interval can be as short as 64 seconds and as long as 1024 seconds.  The way to tell is to look at the value of poll in the output below which indicates how often it polls that server.  As NTP sees consistent and stable time, it will gradually adjust the polling interval upward.  In this example, it polls every 1024 seconds.

router#show ntp associations       
  address         ref clock       st   when   poll reach  delay  offset   disp
+~98.191.213.2    .GPSD.           1     53   1024   377  0.030   0.758  1.093
+~98.191.213.12   .GPSD.           1    468   1024   377  0.003   0.701  1.052
+~98.191.213.14   .GPSD.           1    665   1024   357  0.319   0.189  1.071
*~98.191.213.7    .GPS.            1    235   1024   377  0.054   0.768  1.045
+~192.168.213.7   .GPS.            1    725   1024   377  0.060   0.947  1.040
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

 

In the example below (non-Cisco device), it is polling every 64 seconds:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.46.0    .GPSD.           0 l   37   64  377    0.000   13.134   3.128
o127.127.46.128  .GPSD.           0 l   37   64  377    0.000    0.340   0.046
+98.191.213.2    .GPSD.           1 u   59   64  377    0.329    0.693   0.095
+98.191.213.12   .GPSD.           1 u   17   64  377    0.601    0.449   0.112

The when field tells you when NTP will next poll that server, in seconds.

NTP takes 8 polling cycles to settle into a semi-stable state.  You can see the list of responses by issuing show ntp associations detail.

The reach field is an octal representation of those 8 queries, using a single bit for each query/response.  Each poll will bit shift the reach field to the left, adding a 1 for success or a zero for a failure.  So, if the server returns 8 successful values, the reach field will go 1, 3, 7, 17, 37, 77, 177 and finally 377.  Since the polling interval starts at 64 seconds, it takes 8*64=512 seconds to stabilize, which is 8.53 minutes.

In the first table, you can see that it missed a poll on 98.191.213.14 because the bit field is 357.  After NTP runs a while, you want to see 377 in the reach field, indicating 8 successful polls and responses.  You also want to configure more than one NTP server because if you have too many missed responses, NTP will automatically throw that time server out of its algorithm and pick another one.

Content for Community-Ad

Spotlight Awards 2021