Wired Intelligent Edge

Hi

Am I the only one whose Aruba 2540- and 2620-series switches (firmware branch 16.02.0022m) can't keep their local time in sync when NTP protocol is used?

Configuration:

timesync ntp
no sntp
ntp unicast
ntp server x.x.x.x iburst
ntp enable

Statistics:

(config)# sh ntp statistics

 NTP Global statistics information

 NTP In Packets              : 515             
 NTP Out Packets             : 515             
 NTP Bad Version Packets     : 0               
 NTP Protocol Error Packets  : 0      

(config)# sh ntp status

 NTP Status Information

  NTP Status             : Enabled         NTP Mode        : Unicast         
  Synchronization Status : Synchronized    Peer Dispersion : 0.00000 sec     
  Stratum Number         : 4               Leap Direction  : 0               
  Reference Assoc ID     : 0               Clock Offset    : 8.31725 sec     
  Reference ID           : x.x.x.x         Root Delay      : 0.00246 sec     
  Precision              : 2**-18          Root Dispersion : 8.99180 sec     
  NTP Up Time            : 5d 17h 14m      Time Resolution : 819 nsec        
  Drift                  : 0.00000 sec/sec

  System Time            : Thu May  3 08:52:09 2018                
  Reference Time         : Thu May  3 07:16:20 2018

# sh ntp associations

                            NTP Associations Entries


 Remote          St   T    When   Poll  Reach    Delay    Offset   Dispersion
 --------------- ---- ---- ------ ----- -------- -------- -------- ----------
 x.x.x.x            3    u    495557 10    177      0.000    0.000    16.00000  

After 6 days it's already 8 seconds behind (real time vs. 'show time').

Or have I done something systematically wrong?

Thank You

Tigekala

Can you provide the output of show ntp associations detail <IP ADDR> command (where <IP ADDR> should be changed with your NTP Server x.x.x.x IP address)?

Edit: what happen if you try ntp server x.x.x.x instead of ntp server x.x.x.x iburst?

# show ntp associations detail x.x.x.x

NTP Association Information

IP Address : x.x.x.x            Peer Mode : Server
Status : Config,Sane,Master     Peer Poll Intvl : 17
Stratum : 3                     Root Delay : 0.00165 sec
Ref Assoc ID : 1                Root Dispersion : 0.05344 sec
Assoc Name : NTP Association 1  Reach : 1
Reference ID : 195.80.x.x       Delay : 0.00000 sec
Our Mode : Client               Offset : 0.00000 sec
Our Poll Intvl : 11             Precision : 2**0
Dispersion : 16.00000 sec
Association In Packets : 615
Association Out Packets : 615
Association Error Packets : 0
Origin Time : Mon Jan 1 02:00:00 1990
Receive Time : Mon Jan 1 02:00:00 1990
Transmit Time : Mon Jan 1 02:00:00 1990

-------------------------------------------------------------------------
Filter Delay = 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
Filter Offset = 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000

Without 'iburst' it took minutes for switch to set its local time to smthing else than 01/01/90

Tigekala

After 6 days it's already 8 seconds behind

It's syncing every 17 seconds.

It's hard to call that syncing when switch'es local time differs almost 10 seconds from real time.

The point is, it can't be drifting for 8 days as it is syncing every 17 seconds, so there must be a problem with the sync. (or the source is rubbish).

Personally, I like a single internal source for time, that way I can be sure that all the desktops and all the infrastructure are getting the same time from a local source on the LAN. Also, I don't need multiple devices connecting through my gateway to get NTP - it's more efficient to have just 1 and to have that device redistribute time.

If I have my own source, then I have a Stratum1 NTP server pool that only accepts NTP queries from a second, Stratum 2, server pool that all my other devices query for NTP.
If I have to get time off the internet, then I use an internal NTP server pool to go and get that time and treat that as my "Stratum2" NTP server pool, and have all my internal hosts query that.

---

@Vince-Whirlwind wrote:

... so there must be a problem with the sync. (or the source is rubbish).

---

... although

1) NTP server x.x.x.x seems to feel OK:

ntpq -4 -p -n
remote         refid       st t when poll reach delay  offset jitter
==============================================================================
127.127.1.0   .LOCL.       13 l  65d   64     0 0.000  0.000  0.000
+195.80.xx.xx 195.80.zz.zz  2 u   18 1024   377 0.467 -0.149  0.629
*195.80.yy.yy 195.80.ww.ww  2 u  320  512   377 0.466  0.169  0.262

2) other devices which use x.x.x.x as a (S)NTP server are in sync

3) If I switch from NTP to SNTP then switches are in sync again

UPDATE: upgrade to 16.02.0026 solved the problem. Case closed.