Je viens de remarquer par pur hasard qu'un de mes commutateurs Cisco 4500 a son horloge qui tourne mal: il a plus de 2 minutes de retard malgré un ntp apparemment fonctionnel. À mon avis, même une seule seconde ne devrait pas être considérée comme acceptable pour les systèmes concernés. De plus, je n'aurais pas remarqué la différence avec les diagnostics, si je ne l'avais pas comparé à une simple horloge murale.
Quelques détails
Voici des informations ntp pour certains de mes hôtes (10.0.99.1, 10.0.99.2, 10.0.1.119, 10.0.99.241) qui se réfèrent en partie les uns aux autres pour le repli, mais devraient principalement tous en fin de compte se synchroniser avec 10.0.0.1, qui tire à nouveau la temps de l'extérieur. La différence de temps ne peut donc pas provenir de différentes sources de temps d'origine. Comme les observations m'ont rendu quelque peu paranoïaque, "a l'heure correcte" dans les moyens suivants: show clock(ou date) a produit une sortie qui correspond à mon horloge murale et à mon horloge système locale (ce qui est bien selon http://time.is ) avec une erreur certainement inférieure à 1 seconde (précision de ma frappe ENTRÉE en regardant mon horloge locale)
10.0.1.119 (Ubuntu) a l'heure correcte
$ 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) a l'heure correcte
#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) a l'heure correcte
#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) accuse un retard d'environ 2 minutes 6 secondes
#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.
Des questions
- Comment se fait-il que 10.0.99.1 soit si loin?
- Pourquoi les systèmes qui se synchronisent avec 10.0.99.1 sont-ils corrects?
- Comment dois-je apprendre de la sortie du
sho ntp status10.0.99.1 que l'horloge est réellement totalement désynchronisée (par rapport à tous les hôtes et horloges de référence mentionnés danssho ntp asso)? Pour moi, la sortie ressemble totalement à un "Je suis totalement heureux" très élaboré.
EDIT: à la demande générale, la production desho 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). Mais je pense qu'aucune de mes observations ne peut expliquer directement la cause de votre problème actuel.