Comment se fait-il que l'un de mes commutateurs soit désactivé de deux minutes malgré le ntp?


11

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

  1. Comment se fait-il que 10.0.99.1 soit si loin?
  2. Pourquoi les systèmes qui se synchronisent avec 10.0.99.1 sont-ils corrects?
  3. 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 dans sho 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

Je ne trouve aucun système dans lequel les adresses IP que vous avez configurées en tant que serveurs ntp utilisés par chaque appareil. Et je repère une boucle ainsi qu'un couple utilisant les uns les autres comme serveurs ntp. Je crois que dans ces cas, vous êtes censé les spécifier en tant que pairs ntp plutôt qu'en tant que serveurs. Bien que je dois admettre que je ne sais pas exactement quelle différence cela fait si vous le spécifiez comme pair ou serveur. De plus, je ne suis pas convaincu que ce soit une bonne idée de laisser tout se synchroniser via un seul hôte ( 10.0.0.1). Mais je pense qu'aucune de mes observations ne peut expliquer directement la cause de votre problème actuel.
kasperd

2
Un problème flagrant avec votre configuration ntp est que chaque hôte est configuré avec le pire nombre possible de sources de temps. "Un homme avec une montre sait quelle heure il est, un homme avec deux montres n'est jamais sûr ..." Tout autre nombre vaut mieux que deux, quatre est probablement le meilleur choix, il donne un coussin si on n'est pas disponible et part toujours trois sources.
dfc

4
Toute votre configuration NTP doit être reconsidérée. Vous devez travailler avec des niveaux de strate. Comme l'a souligné @kasperd, vous pourriez avoir un problème avec une boucle. Vous devez uniquement vous synchroniser avec les serveurs avec un niveau de strate inférieur, et ceux du même niveau de strate peuvent être comparés, mais ne pas s’utiliser comme serveurs. Les appareils homologues ont toujours besoin d'un ou de plusieurs serveurs à un niveau de strate inférieur comme source (s) faisant autorité, mais essaieront de s'aligner sur les autres homologues. N'utilisez pas de périphériques occupés (par exemple, des commutateurs principaux) comme serveurs NTP.
Ron Maupin

3
Il se passe quelque chose de très étrange. Toute la sortie ntp est raisonnablement normale et montre une bonne synchronisation. Pourtant, votre commande pour obtenir l'heure de l'appareil a donné un temps qui est loin. Cela suggère que, pour une raison quelconque, le périphérique dont l'heure est désactivée ne règle pas son horloge système à partir de son sous-système ntp.
David Schwartz

1
Il semble vraiment que vous ayez trouvé un bogue, et probablement la seule façon d'aller de l'avant est de le redémarrer et d'espérer qu'il disparaisse ou de contacter Cisco.
derobert

Réponses:


2

Je suis un peu réticent à poster ceci comme réponse parce que la cause originale n'est toujours pas claire. Néanmoins, le problème semble résolu - du moins pour le moment.


Suite aux commentaires de htm11h , j'ai décidé de mettre à jour le firmware. Et en effet, maintenant que j'utilise un firmware plus récent, l'horloge semble correspondre à l'heure correcte.

Mais cela signifie-t-il que le nouveau firmware était la solution? Malheureusement non. Lors de ma première tentative de chargement du nouveau firmware, j'ai oublié de modifier le registre de configuration, qui était toujours sur sa valeur par défaut. Par conséquent, mon premier redémarrage s'est retrouvé dans la même image ROM d'origine que le routeur fonctionnait depuis près de quatre ans (c'est-à-dire depuis sa mise sous tension initiale). Et pourtant, cela suffisait à l'horloge pour effectuer un énorme ajustement et rester synchronisé. Cela suggère qu'un simple redémarrage aurait pu aider - temporairement. À son tour, cela signifie que l'heure maintenant correcte affichée avec le nouveau firmware peut encore s'éloigner du temps ntp au cours des années à venir. Il faudra quelques jours pour que je sache en toute sécurité si l'horloge a perdu environ 5 secondes par jour ...

Pour l'instant, l'affaire est close.


1

J'ai fait pas mal de travail avec le projet NTP Pool depuis le milieu des années 90 et j'ai exécuté plusieurs serveurs NTP Stratum-1 GPS Synced ici. Comme d'autres l'ont déclaré, vous avez besoin de plus de 2 serveurs pour obtenir du temps. J'utilise habituellement 4 ici pour les raisons énoncées par Ron Maupin ci-dessus. Aussi, comme indiqué, vous devez rechercher les boucles et définir les choses en tant que serveurs par rapport à leurs pairs.

La dérive temporelle pourrait être due à un bogue connu dans IOS qui a été corrigé dans cette mise à jour IOS traitant du ntp.drift ne pas être supprimé ou mis à jour correctement et donc le problème de dérive. De plus, 4 ans sans redémarrage ni mise à jour doivent vous avoir laissé dans une mauvaise situation en termes de sécurité, car les mises à jour de sécurité IOS sont assez fréquentes.

Voici un excellent article sur la configuration de NTP sur Cisco IOS http://packetlife.net/blog/2011/mar/28/cisco-ios-clocks-and-ntp/

J'espère que cela vous sera utile. Veuillez demander si vous avez d'autres questions ou problèmes.


0

Divulgation complète: je n'ai que rarement manipulé des configurations de commutateurs, et je ne suis en aucun cas un expert NTP.

Cela dit, j'avais l'habitude de voir le démon NTP sur les systèmes RHEL 5.x (oui, j'y retourne, mais vous avez dit que votre commutateur avait une image vieille de ~ 4 ans ...) coincé dans un état "heureux" , où il semblait penser qu'il était parfaitement synchronisé mais ne l'était clairement pas. Nous utiliserions une session ClusterSSH pour exécuter "date" sur tous les systèmes simultanément, et cela montrerait parfois jusqu'à 5 minutes de dérive entre les systèmes. Si je me souviens bien, nous n'avons pu sembler résoudre le problème qu'en redémarrant le démon, et finalement nous avons juste fait redémarrer cron le service tous les soirs ...

Ce n'est en aucun cas une solution idéale, mais vous pourriez être en mesure d'adopter une approche similaire avec un travail cron pour vous connecter au commutateur et lancer un redémarrage, ou en quelque sorte "lancer" le démon NTP sur le commutateur?

J'espère que cela t'aides!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.