Ho appena notato per puro caso che uno dei miei switch Cisco 4500 ha l'orologio che non va: è più di 2 minuti indietro nonostante apparentemente funzionale ntp. A mio avviso, anche un solo secondo non dovrebbe essere considerato accettabile per i sistemi coinvolti. Inoltre, non avrei notato la differenza rispetto alla diagnostica, se non l'avessi confrontato con un semplice orologio da parete.
Alcuni dettagli
Ecco le informazioni ntp per alcuni dei miei host (10.0.99.1, 10.0.99.2, 10.0.1.119, 10.0.99.241) che si riferiscono in parte l'uno all'altro per fallback, ma principalmente dovrebbero infine alla fine sincronizzarsi con 10.0.0.1, che di nuovo tira il tempo dall'esterno. Quindi la discrepanza temporale non può derivare da diverse fonti temporali originali. Come le osservazioni mi hanno reso un po 'paranoico, "ha l'ora corretta" nei seguenti mezzi: show clock(o date) ha prodotto un output che corrisponde al mio orologio da parete e al mio orologio di sistema locale (che va bene secondo http://time.is ) con un errore sicuramente inferiore a 1 secondo (precisione di quando premo ENTER mentre guardo il mio orologio locale)
10.0.1.119 (Ubuntu) ha l'ora corretta
$ ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
+10.0.99.1 10.0.0.1 3 u 855 1024 377 0.904 -2.658 0.113
*10.0.0.1 130.149.17.8 2 u 266 1024 377 0.253 0.909 0.127
10.0.99.241 (Cisco 2960) ha l'ora corretta
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.99.1 10.0.0.1 3 28 64 377 1.462 85.288 19.758
+~10.0.99.2 10.0.1.119 4 29 64 377 1.297 83.515 5.369
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.2 (Cico 4500) ha l'ora corretta
#sho ntp associations
address ref clock st when poll reach delay offset disp
+~10.0.99.1 10.0.0.1 3 6 1024 111 1.148 -1.618 42.875
*~10.0.1.119 10.0.0.1 3 31 1024 377 0.043 1.687 1.064
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.1 (Cisco 4500) è in ritardo di circa 2 minuti e 6 secondi
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.0.1 130.149.17.8 2 274 1024 377 15.625 3.681 30.403
+~10.0.99.2 10.0.1.119 4 415 1024 376 15.625 0.855 33.276
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
#sho ntp status
Clock is synchronized, stratum 3, reference is 10.0.0.1
nominal freq is 250.0000 Hz, actual freq is 249.9988 Hz, precision is 2**6
reference time is DAD8B428.54C6BAEA (20:36:24.331 MESZ Sat May 7 2016)
clock offset is 3.6818 msec, root delay is 32.80 msec
root dispersion is 71.74 msec, peer dispersion is 30.40 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000004720 s/s
system poll interval is 1024, last update was 683 sec ago.
Domande
- Come mai 10.0.99.1 è così lontano?
- Come mai i sistemi sincronizzati con 10.0.99.1 sono corretti?
- Come devo imparare dall'output di
sho ntp status10.0.99.1 che l'orologio è in realtà totalmente fuori sincrono (rispetto a tutti gli host e gli orologi di riferimento citati insho ntp asso)? Per me l'output sembra totalmente elaborato "Sono totalmente felice".
EDIT: A grande richiesta, l'output disho clock detail
10.0.99.1
#sho clock detail
13:06:38.605 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
10.0.99.2
#sho clock detail
13:10:54.083 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
10.0.0.1). Ma non credo che nessuna delle mie osservazioni possa spiegare direttamente la causa del tuo attuale problema.