Guide de dépannage et de débogage des problèmes liés au protocole NTP (Network Time Protocol)
Contenu
Introduction
Ce document décrit l'utilisation de débogages afin de dépanner des problèmes de protocole NTP (Network Time Protocol), ainsi que le résultat des commandes clé show ntp.
Commandes show NTP
Avant d'examiner la cause des problèmes NTP, vous devez comprendre l'utilisation et la sortie de ces commandes :
- show ntp association
- show ntp association detail
- show ntp status
show ntp association
Une association NTP peut être une association homologue (un système est prêt à se synchroniser avec l'autre système ou à permettre à l'autre système de se synchroniser avec lui) ou une association serveur (un seul système se synchronise avec l'autre système et non l'inverse).
Voici un exemple de sortie de la commande show ntp association :
CLA_PASA#sh ntp association
address ref clock st when poll reach delay offset disp
~127.127.7.1 127.127.7.1 9 50 64 377 0.0 0.00 0.0
~10.50.44.69 10.50.36.106 5 21231 1024 0 3.8 -4.26 16000.
+~10.50.44.101 10.50.38.114 5 57 64 1 3.6 -4.30 15875.
+~10.50.44.37 10.50.36.50 5 1 256 377 0.8 1.24 0.2
~10.50.44.133 10.50.38.170 5 12142 1024 0 3.2 1.24 16000.
+~10.50.44.165 10.50.38.178 5 35 256 357 2.5 -4.09 0.2
+~10.50.38.42 86.79.127.250 4 7 256 377 0.8 -0.29 0.2
*~10.50.36.42 86.79.127.250 4 188 256 377 0.7 -0.17 0.3
+~10.50.38.50 86.79.127.250 4 42 256 377 0.9 1.02 0.4
+~10.50.36.50 86.79.127.250 4 20 256 377 0.7 0.87 0.5
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
| Terme | Explication |
|---|---|
Les caractères précédant l'adresse ont les définitions suivantes :
|
|
adresse |
Il s’agit de l’adresse IP de l’homologue. Dans l'exemple, la première entrée affiche 127.127.7.1. Cela indique que la machine locale s'est synchronisée avec elle-même. Généralement, seul un maître NTP se synchronise avec lui-même. |
horloge de référence |
Il s’agit de l’adresse de l’horloge de référence de l’homologue. Dans l’exemple, les six premiers homologues/serveurs ont une adresse IP privée comme horloge de référence, de sorte que leurs maîtres sont probablement des routeurs, des commutateurs ou des serveurs au sein du réseau local. Pour les quatre dernières entrées, l'horloge de référence est une adresse IP publique, de sorte que leurs maîtres sont probablement une source temporelle publique. |
st |
NTP utilise le concept de strate afin de décrire la distance (en sauts NTP) à laquelle une machine provient d'une source temporelle faisant autorité. Par exemple, un serveur de temps de strate 1 est directement relié à une radio ou à une horloge atomique. Il envoie son temps à un serveur de temps de strate 2 via NTP, et ainsi de suite jusqu'à la strate 16. Une machine exécutant NTP choisit automatiquement la machine dont le numéro de strate est le plus bas et qui utilise NTP comme source temporelle. |
quand |
Le temps écoulé depuis la réception du dernier paquet NTP par un homologue est signalé en secondes. Cette valeur doit être inférieure à l'intervalle d'interrogation. |
sonder |
L'intervalle d'interrogation est signalé en secondes. L'intervalle commence généralement par un intervalle d'interrogation minimal de 64 secondes. Le document RFC spécifie qu'il n'est pas nécessaire d'effectuer plus d'une transaction NTP par minute pour synchroniser deux machines. Comme le protocole NTP devient stable entre un client et un serveur, l'intervalle d'interrogation peut augmenter en petites étapes de 64 secondes à 1024 secondes et se stabiliser généralement quelque part entre les deux. Mais cette valeur change dynamiquement, en fonction des conditions réseau entre le client et le serveur et de la perte de paquets NTP. Si un serveur est inaccessible pendant un certain temps, l'intervalle d'interrogation est augmenté en étapes pour atteindre 1 024 secondes afin de réduire la surcharge du réseau. Il n'est pas possible d'ajuster l'intervalle d'interrogation NTP sur un routeur, car l'intervalle interne est déterminé par des algorithmes heuristiques. |
atteindre |
L'accessibilité des homologues est une chaîne de bits signalée comme valeur octale. Ce champ indique si les huit derniers paquets ont été reçus par le processus NTP sur le logiciel Cisco IOS®. Les paquets doivent être reçus, traités et acceptés comme valides par le processus NTP et pas seulement par le routeur ou le commutateur qui reçoit les paquets IP NTP. Reach utilise l'intervalle d'interrogation pour un délai d'attente afin de décider si un paquet a été reçu ou non. L'intervalle d'interrogation est le temps que NTP attend avant de conclure qu'un paquet a été perdu. Le temps d'interrogation peut être différent pour différents homologues, de sorte que le temps avant la portée décide qu'un paquet a été perdu peut également être différent pour différents homologues. Dans l'exemple, il existe quatre valeurs de portée différentes :
Reach est un bon indicateur pour savoir si les paquets NTP sont abandonnés en raison d'une liaison médiocre, de problèmes de CPU et d'autres problèmes intermittents. Convert octal < - > binary est un convertisseur d'unité en ligne pour cette conversion et bien d'autres. |
retard |
Le délai aller-retour vers l'homologue est signalé en millisecondes. Afin de définir l'horloge avec plus de précision, ce délai est pris en compte lorsque l'heure d'horloge est définie. |
compensation |
Décalage est la différence de temps d'horloge entre les homologues ou entre le maître et le client. Cette valeur est la correction appliquée à une horloge client afin de la synchroniser. Une valeur positive indique que l'horloge du serveur est supérieure. Une valeur négative indique que l'horloge du client est supérieure. |
disp |
La dispersion, signalée en secondes, est la différence de temps d'horloge maximale qui a été observée entre l'horloge locale et l'horloge du serveur. Dans l'exemple, la dispersion est 0,3 pour le serveur 10.50.36.42, de sorte que la différence de temps maximale jamais observée localement entre l'horloge locale et l'horloge du serveur est de 0,3 secondes. Vous pouvez vous attendre à voir une valeur élevée lorsque les horloges sont synchronisées initialement. Mais si la dispersion est trop élevée à d'autres moments, le processus NTP sur le client n'accepte pas les messages NTP du serveur. La dispersion maximale est de 16 000 ; dans l'exemple, il s'agit de la dispersion pour les serveurs 10.50.44.69 et 10.50.44.133, de sorte que le client local n'accepte pas le temps de ces serveurs. Si la portée est nulle et que la dispersion est très élevée, le client n'accepte probablement pas les messages de ce serveur. Reportez-vous à la deuxième ligne de l'exemple : address ref clock st when poll reach delay offset disp Même si le décalage est juste -4,26, la dispersion est très élevée (peut-être à cause d'un événement passé), et la portée est zéro, donc ce client n'accepte pas le temps de ce serveur. |
show ntp association detail
Voici un exemple de sortie de la commande show ntp association detail :
Router#sho ntp assoc detail
10.4.2.254 configured, our_master, sane, valid, stratum 1
ref ID .GPS., time D36968AA.CC528FE7 (02:10:50.798 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.44, reach 377, sync dist 207.565
delay 2.99 msec, offset 268.3044 msec, dispersion 205.54
precision 2**19, version 3
org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012)
rcv time D36968B7.A2F44E2C (02:11:03.636 UTC Fri May 25 2012)
xmt time D36968B7.A21D3780 (02:11:03.633 UTC Fri May 25 2012)
filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72
filtoffset = 268.30 172.15 -452.49 -253.59 -462.03 -81.98 -58.04 22.38
filterror = 0.02 0.99 1.95 1.97 2.00 2.01 2.03 2.04
10.3.2.254 configured, selected, sane, valid, stratum 1
ref ID .GPS., time D36968BB.B16C4A21 (02:11:07.693 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 3.34, reach 377, sync dist 192.169
delay 0.84 msec, offset 280.3251 msec, dispersion 188.42
precision 2**19, version 3
org time D36968BD.E69085E4 (02:11:09.900 UTC Fri May 25 2012)
rcv time D36968BD.9EE9048B (02:11:09.620 UTC Fri May 25 2012)
xmt time D36968BD.9EA943EF (02:11:09.619 UTC Fri May 25 2012)
filtdelay = 0.84 0.75 663.68 0.67 0.72 968.05 714.07 1.14
filtoffset = 280.33 178.13 -286.52 42.88 41.41 -444.37 -320.25 35.15
filterror = 0.02 0.99 1.97 1.98 1.98 2.00 2.03 2.03
10.1.2.254 configured, insane, invalid, stratum 1
ref ID .GPS., time D3696D3D.BBB4FF24 (02:30:21.733 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 4.15, reach 1, sync dist 15879.654
delay 0.98 msec, offset 11.9876 msec, dispersion 15875.02
precision 2**19, version 3
org time D3696D3D.E4C253FE (02:30:21.893 UTC Fri May 25 2012)
rcv time D3696D3D.E1D0C1B9 (02:30:21.882 UTC Fri May 25 2012)
xmt time D3696D3D.E18A748D (02:30:21.881 UTC Fri May 25 2012)
filtdelay = 0.98 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 11.99 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 0.02 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
Les termes déjà définis dans la section show ntp association ne sont pas répétés.
Terme |
Explication | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
configuré |
Cette source d'horloge NTP a été configurée pour être un serveur. Cette valeur peut également être dynamique, où l'homologue/serveur a été découvert dynamiquement. |
|||||||||||||||||||||||||||
notre_maître |
Le client local est synchronisé avec cet homologue. |
|||||||||||||||||||||||||||
sélectionné |
L'homologue/serveur est sélectionné pour une synchronisation possible, lorsque 'our_master' échoue ou que le client perd la synchronisation. |
|||||||||||||||||||||||||||
sain d'esprit |
Des tests d'intégrité sont utilisés afin de tester le paquet NTP reçu d'un serveur. Ces tests sont spécifiés dans RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis . Les tests sont les suivants :
Les données de paquet sont valides si les tests 1 à 4 sont réussis. Les données sont ensuite utilisées pour calculer le décalage, le délai et la dispersion. L’en-tête de paquet est valide si les tests 5 à 8 sont réussis. Seuls les paquets avec un en-tête valide peuvent être utilisés pour déterminer si un homologue peut être sélectionné pour la synchronisation. |
|||||||||||||||||||||||||||
fou |
Les contrôles de bon fonctionnement ont échoué, de sorte que le temps du serveur n'est pas accepté. Le serveur n'est pas synchronisé. |
|||||||||||||||||||||||||||
valide |
L'heure homologue/serveur est valide. Le client local accepte cette fois si cet homologue devient le maître. |
|||||||||||||||||||||||||||
non valide |
L'heure homologue/serveur n'est pas valide et l'heure ne sera pas acceptée. |
|||||||||||||||||||||||||||
ID réf |
Un ID de référence (étiquette) est attribué à chaque homologue/serveur. |
|||||||||||||||||||||||||||
Heure |
L'heure est le dernier horodatage reçu de cet homologue/serveur. |
|||||||||||||||||||||||||||
notre mode/homologue |
Il s'agit de l'état du client/homologue local. |
|||||||||||||||||||||||||||
notre sonl intvl/ peer poll intvl |
Il s'agit de l'intervalle de sondage entre notre sondage et cet homologue ou entre l'homologue et la machine locale. |
|||||||||||||||||||||||||||
délai racine |
Le délai racine est le délai en millisecondes à la racine de la configuration NTP. Les horloges de strate 1 sont considérées comme étant à la racine d'une configuration/conception NTP. Dans l'exemple, les trois serveurs peuvent être la racine car ils se trouvent à la strate 1. |
|||||||||||||||||||||||||||
dispersion des racines |
La dispersion de la racine est la différence de temps d'horloge maximale jamais observée entre l'horloge locale et l'horloge racine. Reportez-vous à l'explication de 'disp' dans la section show ntp association pour plus de détails. |
|||||||||||||||||||||||||||
sync dist. |
Il s'agit d'une estimation de la différence maximale entre le temps sur la source de la strate 0 et le temps mesuré par le client ; il se compose de composants pour le temps aller-retour, la précision du système et la dérive de l'horloge depuis la dernière lecture réelle de la source de la strate. Dans une configuration NTP de grande taille (serveurs NTP à la strate 1 sur Internet, avec des serveurs qui génèrent du temps à différentes couches) avec des serveurs/clients à plusieurs couches, la topologie de synchronisation NTP doit être organisée afin de produire la plus grande précision, mais ne doit jamais être autorisée à former une boucle de synchronisation temporelle. Un autre facteur est que chaque incrément de strate implique un serveur temporel potentiellement non fiable, ce qui introduit des erreurs de mesure supplémentaires. L'algorithme de sélection utilisé dans NTP utilise une variante de l'algorithme de routage distribué Bellman-Ford afin de calculer le nombre minimal de spanning tree enracinés sur les serveurs principaux. La métrique de distance utilisée par l'algorithme consiste en la strate plus la distance de synchronisation, qui elle-même consiste en la dispersion plus la moitié du délai absolu. Ainsi, le chemin de synchronisation amène toujours le nombre minimum de serveurs à la racine ; les liens sont résolus sur la base d'une erreur maximale. |
|||||||||||||||||||||||||||
retard |
Il s'agit du délai aller-retour vers l'homologue. |
|||||||||||||||||||||||||||
précision |
C'est la précision de l'horloge homologue en Hz. |
|||||||||||||||||||||||||||
version |
Il s'agit du numéro de version NTP utilisé par l'homologue. |
|||||||||||||||||||||||||||
heure de l'organisation |
Il s'agit de l'horodatage de l'initiateur de paquet NTP ; en d'autres termes, c'est l'horodatage de cet homologue lorsqu'il a créé le paquet NTP, mais avant d'envoyer le paquet au client local. |
|||||||||||||||||||||||||||
temps rcv |
Horodatage lorsque le client local a reçu le message. La différence entre le temps d'organisation et le temps de réception est le décalage pour cet homologue. Dans l'exemple, le maître 10.4.2.254 a les durées suivantes : org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012) La différence est le décalage de 268,3044 ms. |
|||||||||||||||||||||||||||
xmt time |
Il s’agit de l’horodatage de transmission du paquet NTP que le client local envoie à cet homologue/serveur. |
|||||||||||||||||||||||||||
filtdelay |
Il s'agit du délai aller-retour en millisecondes de chaque échantillon. Un exemple est le dernier paquet NTP reçu. Dans l'exemple, le maître 10.4.2.254 a les valeurs suivantes : filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72 Ces huit échantillons correspondent à la valeur du champ d'accès, qui indique si le client local a reçu les huit derniers paquets NTP. |
show ntp status
Voici un exemple de sortie de la commande show ntp status :
USSP-B33S-SW01#sho ntp status
Clock is synchronized, stratum 2, reference is 10.4.2.254
nominal freq is 250.0000 Hz, actual freq is 250.5630 Hz, precision is 2**18
reference time is D36968F7.7E3019A9 (02:12:07.492 UTC Fri May 25 2012)
clock offset is 417.2868 msec, root delay is 2.85 msec
root dispersion is 673.42 msec, peer dispersion is 261.80 msec
Les termes déjà définis dans la section show ntp association ou la section show ntp association details ne sont pas répétés.
| Terme | Explication |
|---|---|
précision |
La précision est déterminée automatiquement et mesurée comme une puissance de deux. Dans l’exemple, 2**18 signifie 2^(-18) ou 3,8 microsecondes. La perte de synchronisation entre des homologues NTP ou entre un maître et un client peut être due à diverses causes. NTP évite la synchronisation avec une machine dont l'heure peut être ambiguë de ces manières :
|
Dépannage de NTP avec des débogages
Voici quelques-unes des causes les plus courantes des problèmes liés au protocole NTP :
- Les paquets NTP ne sont pas reçus.
- Les paquets NTP sont reçus, mais ne sont pas traités par le processus NTP sur IOS.
- Les paquets NTP sont traités, mais des facteurs erronés ou des données de paquets entraînent la perte de synchronisation.
- La période d'horloge NTP est définie manuellement.
Les commandes de débogage importantes qui permettent d'isoler la cause de ces problèmes sont les suivantes :
- debug ip packets <acl>
- debug ntp packets
- debug ntp authentication
- debug ntp sync
- debug ntp events
Les sections suivantes illustrent l'utilisation des débogages afin de résoudre ces problèmes courants.
Paquets NTP non reçus
Utilisez la commande debug ip packet afin de vérifier si des paquets NTP sont reçus et envoyés. Puisque la sortie de débogage peut être chatty, vous pouvez limiter la sortie de débogage avec l'utilisation des listes de contrôle d'accès (ACL). Le protocole NTP utilise le port 123 du protocole UDP (User Datagram Protocol).
- Créer la liste de contrôle d’accès 101 :
access-list 101 permit udp any any eq 123
Les paquets NTP ont généralement un port source et de destination de 123, ce qui aide à :
access-list 101 permit udp any eq 123 any
permit udp any eq 123 any eq 123
- Utilisez cette liste de contrôle d’accès afin de limiter la sortie de la commande debug ip packet :
debug ip packet 101
- Si le problème concerne des homologues particuliers, limitez la liste de contrôle d’accès 101 à ces homologues. Si l’homologue est 172.16.1.1, remplacez la liste de contrôle d’accès 101 par :
access-list 101 permit udp host 172.16.1.1 any eq 123
access-list 101 permit udp any eq 123 host 172.16.1.1
Cet exemple de sortie indique que les paquets ne sont pas envoyés :
241925: Apr 23 2012 15:46:26.101 ETE: IP: s=10.50.38.70 (Tunnel99), d=10.50.44.101, len 76,
input feature
241926: Apr 23 2012 15:46:26.101 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0,
forus FALSE, sendself FALSE, mtu 0
241927: Apr 23 2012 15:46:26.101 ETE: IP: s=10.50.38.70 (Tunnel99), d=10.50.44.101, len 76,
input feature
241928: Apr 23 2012 15:46:26.101 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0,
forus FALSE, sendself FALSE, mtu 0
Une fois que vous avez confirmé que les paquets NTP ne sont pas reçus, vous devez :
- Vérifiez si NTP est configuré correctement.
- Vérifiez si une liste de contrôle d’accès bloque les paquets NTP.
- Recherchez les problèmes de routage vers l'adresse IP source ou de destination.
Paquets NTP non traités
Avec les commandes debug ip packet et debug ntp packets activées, vous pouvez voir les paquets qui sont reçus et transmis, et vous pouvez voir que NTP agit sur ces paquets. Pour chaque paquet NTP reçu (comme indiqué par debug ip packet), il y a une entrée correspondante générée par debug ntp packets.
Voici la sortie de débogage lorsque le processus NTP fonctionne sur les paquets reçus :
Apr 20 00:16:34.143 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), routed
via FIB
.Apr 20 00:16:34.143 UTC: IP: s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:34.143 UTC: IP: s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), len 76, sending
full packet
.Apr 20 00:16:34.143 UTC: NTP: xmit packet to 10.1.2.254:
.Apr 20 00:16:34.143 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:34.143 UTC: rtdel 0021 (0.504), rtdsp 1105E7 (17023.056), refid 0A0102FE
(10.1.2.254)
.Apr 20 00:16:34.143 UTC: ref D33B2922.24FEBDC7 (00:15:30.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:34.143 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: IP: s=10.1.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:34.143 UTC: NTP: rcv packet from 10.1.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:34.143 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:34.143 UTC: rtdel 0000 (0.000), rtdsp 009D (2.396), refid 47505300 (71.80.83.0)
.Apr 20 00:16:34.143 UTC: ref D33B2952.4CC11CCF (00:16:18.299 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: rec D33B2962.49D3724D (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.49D997D0 (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: inp D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), routed
via FIB
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending
full packet
.Apr 20 00:16:36.283 UTC: NTP: xmit packet to 10.8.2.254:
.Apr 20 00:16:36.283 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 002F (0.717), rtdsp 11058F (17021.713), refid 0A0102FE
(10.1.2.254)
.Apr 20 00:16:36.283 UTC: ref D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: s=10.8.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:36.283 UTC: NTP: rcv packet from 10.8.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:36.283 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 0000 (0.000), rtdsp 0017 (0.351), refid 47505300 (71.80.83.0)
.Apr 20 00:16:36.283 UTC: ref D33B295B.8AF7FE33 (00:16:27.542 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: rec D33B2964.4A6AD269 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.4A7C00D0 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: inp D33B2964.498A755D (00:16:36.287 UTC Fri Apr 20 2012)
Ceci est un exemple où NTP ne fonctionne pas sur les paquets reçus. Bien que les paquets NTP soient reçus (comme indiqué par les paquets ip de débogage), le processus NTP ne les exécute pas. Pour les paquets NTP envoyés, un résultat debug ntp correspondant est présent, car le processus NTP doit générer le paquet. Le problème est spécifique aux paquets NTP reçus qui ne sont pas traités.
071564: Apr 23 2012 15:46:26.100 ETE: NTP: xmit packet to 10.50.44.101:
071565: Apr 23 2012 15:46:26.100 ETE: leap 0, mode 1, version 3, stratum 5, ppoll 1024
071566: Apr 23 2012 15:46:26.100 ETE: rtdel 07B5 (30.106), rtdsp 0855 (32.547), refid 0A32266A
(10.50.38.106)
071567: Apr 23 2012 15:46:26.100 ETE: ref D33FDB05.1A084831 (15:43:33.101 ETE Mon Apr 23 2012)
071568: Apr 23 2012 15:46:26.100 ETE: org 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071569: Apr 23 2012 15:46:26.100 ETE: rec 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071570: Apr 23 2012 15:46:26.100 ETE: xmt D33FDBB2.19D3457C (15:46:26.100 ETE Mon Apr 23 2012)
PCY_PAS1#
071571: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76,
input feature
071572: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0,
forus FALSE, sendself FALSE, mtu 0
071573: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76,
input feature
071574: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0,
forus FALSE, sendself FALSE, mtu 0
071575: Apr 23 2012 15:47:31.497 ETE: FIBipv4-packet-proc: route packet from Tunnel99 src
10.50.38.78 dst 10.50.44.69
071576: Apr 23 2012 15:47:31.497 ETE: FIBfwd-proc: base:10.50.44.69/32 receive entry
PCY_PAS1#
071577: Apr 23 2012 15:47:31.497 ETE: FIBipv4-packet-proc: packet routing failed
071578: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, rcvd 2
071579: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123
071580: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, stop
process pak for forus packet
071581: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123
PCY_PAS1#
071582: Apr 23 2012 16:03:30.105 ETE: NTP: xmit packet to 10.50.44.101:
071583: Apr 23 2012 16:03:30.105 ETE: leap 0, mode 1, version 3, stratum 5, ppoll 1024
071584: Apr 23 2012 16:03:30.105 ETE: rtdel 0759 (28.702), rtdsp 087D (33.157), refid 0A32266A
(10.50.38.106)
071585: Apr 23 2012 16:03:30.105 ETE: ref D33FDF05.1B2CC3D4 (16:00:37.106 ETE Mon Apr 23 2012)
071586: Apr 23 2012 16:03:30.105 ETE: org 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071587: Apr 23 2012 16:03:30.105 ETE: rec 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071588: Apr 23 2012 16:03:30.105 ETE: xmt D33FDFB2.1B1D5E7E (16:03:30.105 ETE Mon Apr 23 2012)
PCY_PAS1#
071589: Apr 23 2012 16:04:35.502 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76,
input feature
071590: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0,
forus FALSE, sendself FALSE, mtu 0
071591: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76,
input feature
071592: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0, forus
FALSE, sendself FALSE, mtu 0
071593: Apr 23 2012 16:04:35.506 ETE: FIBipv4-packet-proc: route packet from Tunnel99 src
10.50.38.78 dst 10.50.44.69
071594: Apr 23 2012 16:04:35.506 ETE: FIBfwd-proc: base:10.50.44.69/32 receive entry
PCY_PAS1#
071595: Apr 23 2012 16:04:35.506 ETE: FIBipv4-packet-proc: packet routing failed
071596: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, rcvd 2
071597: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123
071598: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, stop
process pak for forus packet
071599: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123
PCY_PAS1#
Perte de synchronisation
La perte de synchronisation peut se produire si la valeur de dispersion et/ou de délai d'un serveur est très élevée. Les valeurs élevées indiquent que les paquets mettent trop de temps à atteindre le client à partir du serveur/homologue en référence à la racine de l'horloge. Ainsi, la machine locale ne peut pas faire confiance à la précision du temps présent dans le paquet, car elle ne sait pas combien de temps il a fallu au paquet pour arriver ici.
NTP est méticuleux quant au temps et ne se synchronisera pas avec un autre périphérique auquel il ne peut pas faire confiance ou ne peut pas s'ajuster d'une manière qui lui permette d'être fiable.
S'il y a une liaison saturée et que la mise en mémoire tampon se produit en cours de route, les paquets sont retardés lorsqu'ils arrivent au client NTP. Ainsi, l'horodatage contenu dans un paquet NTP ultérieur peut parfois varier beaucoup, et le client local ne peut pas vraiment s'ajuster à cette variance.
NTP ne propose pas de méthode pour désactiver la validation de ces paquets, sauf si vous utilisez SNTP (Simple Network Time Protocol). Le protocole SNTP n'est peut-être pas une solution de remplacement car il n'est pas largement pris en charge dans les logiciels.
En cas de perte de synchronisation, vérifiez les liens suivants :
- Sont-ils saturés ?
- Y a-t-il des pertes dans vos liaisons de réseau étendu (WAN) ?
- Le chiffrement est-il en cours ?
Surveillez la valeur de portée à partir de la commande show ntp associations detail. La valeur la plus élevée est 377. Si la valeur est égale ou inférieure à 0, les paquets NTP sont reçus par intermittence et le client local n'est pas synchronisé avec le serveur.
debug ntp authentication
La commande debug ntp validité indique si le paquet NTP a échoué aux contrôles de validité ou de bon fonctionnement et indique la raison de l'échec. Comparez cette sortie aux tests de bon sens spécifiés dans la RFC1305 qui sont utilisés afin de tester le paquet NTP reçu d'un serveur. Huit tests sont définis :
| Tester | Masque | Explication |
|---|---|---|
| 1 | 0x01 | Paquet dupliqué reçu |
| 2 | 0x02 | Paquet incorrect reçu |
| 3 | 0x04 | Protocole non synchronisé |
| 4 | 0x08 | Échec de la vérification de la limite du délai d'homologue/dispersion |
| 5 | 0x10 | Échec de l'authentification homologue |
| 6 | 0x20 | Horloge homologue non synchronisée (commune pour le serveur non synchronisé) |
| 7 | 0x40 | strate homologue hors liaison |
| 8 | 0x80 | Échec de la vérification de la limite de délai/dispersion de la racine |
Voici un exemple de sortie de la commande debug ntp validité :
PCY_PAS1#debug ntp validity
NTP peer validity debugging is on
009585: Mar 1 2012 09:14:32.670 HIVER: NTP: packet from 192.196.113.57 failed validity tests 52
009586: Mar 1 2012 09:14:32.670 HIVER: Authentication failed
009587: Mar 1 2012 09:14:32.670 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009588: Mar 1 2012 09:14:38.210 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009589: Mar 1 2012 09:14:38.210 HIVER: Authentication failed
PCY_PAS1#
009590: Mar 1 2012 09:14:43.606 HIVER: NTP: packet from 163.110.103.27 failed validity tests 14
009591: Mar 1 2012 09:14:43.606 HIVER: Authentication failed
PCY_PAS1#
009592: Mar 1 2012 09:14:48.686 HIVER: NTP: packet from 192.196.113.57 failed validity tests 52
009593: Mar 1 2012 09:14:48.686 HIVER: Authentication failed
009594: Mar 1 2012 09:14:48.686 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009596: Mar 1 2012 09:14:54.222 HIVER: NTP: packet from 163.110.103.35 failed validity tests 14
009597: Mar 1 2012 09:14:54.222 HIVER: Authentication failed
PCY_PAS1#
009598: Mar 1 2012 09:14:54.886 HIVER: NTP: synced to new peer 10.50.38.106
009599: Mar 1 2012 09:14:54.886 HIVER: NTP: 10.50.38.106 synced to new peer
PCY_PAS1#
009600: Mar 1 2012 09:14:59.606 HIVER: NTP: packet from 163.110.103.27 failed validity tests 14
009601: Mar 1 2012 09:14:59.606 HIVER: Authentication failed
PCY_PAS1#
009602: Mar 1 2012 09:15:04.622 HIVER: NTP: packet from 192.196.113.137 failed validity tests 52
009603: Mar 1 2012 09:15:04.622 HIVER: Authentication failed
009604: Mar 1 2012 09:15:04.622 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009605: Mar 1 2012 09:15:10.238 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009606: Mar 1 2012 09:15:10.238 HIVER: Authentication failed
PCY_PAS1#
009607: Mar 1 2012 09:15:15.338 HIVER: NTP: packet from 163.83.23.140 failed validity tests 52
009608: Mar 1 2012 09:15:15.338 HIVER: Authentication failed
009609: Mar 1 2012 09:15:15.338 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009610: Mar 1 2012 09:15:20.402 HIVER: NTP: packet from 192.196.113.92 failed validity tests 74
009611: Mar 1 2012 09:15:20.402 HIVER: Authentication failed
009612: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Clock unsynchronized
009613: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Stratum out of bound
debug ntp packets
Vous pouvez utiliser la commande debug ntp packets afin de voir l'heure que l'homologue/serveur vous donne dans le paquet reçu. L'heure locale indique également l'heure qu'il connaît à l'homologue/serveur dans le paquet transmis.
| Champ | paquet rcv | xmit Packet |
|---|---|---|
| org | Horodatage de l'expéditeur, qui est l'heure du serveur. | Horodatage de l’expéditeur (client) lors de l’envoi du paquet. (Le client envoie un paquet au serveur.) |
| rec | Horodatage sur le client lors de la réception du paquet. | Heure actuelle du client. |
Dans cet exemple de sortie, les horodatages du paquet reçu du serveur et du paquet envoyé à un autre serveur sont identiques, ce qui indique que le NTP client est synchronisé.
USSP-B33S-SW01#debug ntp packets
NTP packets debugging is on
USSP-B33S-SW01#
May 25 02:21:48.182 UTC: NTP: rcv packet from 10.1.2.254 to 10.3.2.31 on Vlan2:
May 25 02:21:48.182 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:21:48.182 UTC: rtdel 0000 (0.000), rtdsp 00F2 (3.693), refid 47505300 (71.80.83.0)
May 25 02:21:48.182 UTC: ref D3696B38.B722C417 (02:21:44.715 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: org D3696B3C.2EA179BA (02:21:48.182 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: rec D3696B3D.E58DE1BE (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: xmt D3696B3D.E594E7AF (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: inp D3696B3C.2EDFC333 (02:21:48.183 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:22:46.051 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:22:46.051 UTC: rtdel 00C0 (2.930), rtdsp 1C6FA (1777.252), refid 0A0402FE (10.4.2.254)
May 25 02:22:46.051 UTC: ref D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: org D3696B37.E72C75AE (02:21:43.903 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: rec D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: xmt D3696B76.0D43AE7D (02:22:46.051 UTC Fri May 25 2012)
Voici un exemple de sortie lorsque les horloges ne sont pas synchronisées. Notez la différence de temps entre le paquet de sortie et le paquet rcv. La dispersion de l'homologue sera égale à la valeur maximale de 16 000 et la portée de l'homologue sera égale à 0.
USSP-B33S-SW01#
.May 25 02:05:59.011 UTC: NTP: xmit packet to 10.4.2.254:
.May 25 02:05:59.011 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.May 25 02:05:59.011 UTC: rtdel 00A3 (2.487), rtdsp 1104D0 (17018.799), refid 0A0402FE
(10.4.2.254)
.May 25 02:05:59.011 UTC: ref D3696747.03D8661A (02:04:55.015 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.May 25 02:05:59.011 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.May 25 02:05:59.011 UTC: xmt D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
.May 25 02:05:59.011 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.May 25 02:05:59.011 UTC: rtdel 0000 (0.000), rtdsp 0014 (0.305), refid 47505300 (71.80.83.0)
.May 25 02:05:59.011 UTC: ref D3696782.C96FD778 (02:05:54.786 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: rec D3696787.281A963F (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: xmt D3696787.282832C4 (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: inp D3696787.03C63542 (02:05:59.014 UTC Fri May 25 2012)
debug ntp sync et debug ntp events
La commande debug ntp sync génère des sorties d'une ligne qui indiquent si l'horloge a été synchronisée ou si la synchronisation a été modifiée. La commande est généralement activée avec les événements debug ntp.
La commande debug ntp events affiche tous les événements NTP qui se produisent, ce qui vous aide à déterminer si une modification dans NTP a déclenché un problème tel que les horloges qui ne sont pas synchronisées. (En d'autres termes, si vos horloges joyeusement synchronisées deviennent soudainement folles, vous savez chercher un changement ou un déclencheur !)
Voici un exemple des deux débogages. Au départ, les horloges du client ont été synchronisées. La commande debug ntp events montre qu'un changement de strate d'homologue NTP s'est produit, et que les horloges sont ensuite désynchronisées.
USSP-B33S-SW01#debug ntp sync
NTP clock synchronization debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
USSP-B33S-SW01#debug ntp events
NTP events debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
May 25 02:25:57.620 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:25:57.620 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:25:57.620 UTC: rtdel 00D4 (3.235), rtdsp 26B26 (2418.549), refid 0A0402FE (10.4.2.254)
May 25 02:25:57.620 UTC: ref D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696BF7.E5F91077 (02:24:55.898 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
May 25 02:25:57.620 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:25:57.620 UTC: rtdel 0000 (0.000), rtdsp 000E (0.214), refid 47505300 (71.80.83.0)
May 25 02:25:57.620 UTC: ref D3696C37.D528800E (02:25:59.832 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696C37.E5C7AB3D (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C37.E5D1F273 (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: inp D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:25:59.830 UTC: NTP: clock reset
May 25 02:25:59.830 UTC: NTP: sync change
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:26:05.817 UTC: NTP: xmit packet to 10.1.2.254:
May 25 02:26:05.817 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
May 25 02:26:05.817 UTC: rtdel 00C2 (2.960), rtdsp 38E9C (3557.068), refid 0A0402FE (10.4.2.254)
May 25 02:26:05.817 UTC: ref D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:26:05.817 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: xmt D3696C3D.D12D0565 (02:26:05.817 UTC Fri May 25 2012)
Période d'horloge NTP définie manuellement
Le site Web Cisco.com avertit que :
« La commande ntp clock-Period est automatiquement générée pour refléter le facteur de correction en constante évolution lorsque la commande copy running-configuration startup-configuration est entrée pour enregistrer la configuration dans la mémoire NVRAM. N'essayez pas d'utiliser manuellement la commande ntp clock-Period. Assurez-vous de supprimer cette ligne de commande lors de la copie des fichiers de configuration sur d'autres périphériques. »
La valeur de la période d'horloge dépend du matériel, elle diffère donc pour chaque périphérique.
La commande ntp clock-Period apparaît automatiquement dans la configuration lorsque vous activez NTP. La commande est utilisée afin de régler l'horloge du logiciel. La 'valeur d'ajustement' compense l'intervalle de graduation de 4 ms, de sorte qu'avec l'ajustement mineur, vous avez 1 seconde à la fin de l'intervalle.
Si le périphérique a calculé que son horloge système perd du temps (il doit peut-être y avoir une compensation de fréquence par rapport au niveau de base du routeur), il ajoute automatiquement cette valeur à l'horloge système afin de maintenir sa synchronisation.
La période d’horloge NTP par défaut d’un routeur est 17179869 et est essentiellement utilisée pour démarrer le processus NTP.
La formule de conversion est 17179869 * 2^(-32) = 0,00399999999957159161567898828125, soit environ 4 millimètres secondes.
Par exemple, l'horloge système des routeurs Cisco 2611 (l'un des routeurs de la gamme Cisco 2600) s'est révélée légèrement désynchronisée et a pu être resynchronisée avec cette commande :
ntp clock-period 17208078
Cela équivaut à 17208078 * 2^(-32) = 0,0040065678777859935760498046875, soit un peu plus de 4 millisecondes secondes.
Cisco vous recommande de laisser le routeur fonctionner pendant une semaine environ dans des conditions normales de réseau, puis d'utiliser la commande wr mem afin d'enregistrer la valeur. Cela vous donne une figure précise pour le prochain redémarrage et permet à NTP de se synchroniser plus rapidement.
Utilisez la commande no ntp clock-Period lorsque vous enregistrez la configuration pour l'utiliser sur un autre périphérique, car cette commande ramène la période d'horloge à la valeur par défaut de ce périphérique particulier. La valeur réelle sera recalculée (mais réduira la précision de l'horloge système au cours de cette période de recalcul).
N'oubliez pas que cette valeur dépend du matériel. Par conséquent, si vous copiez une configuration et que vous l'utilisez sur différents périphériques, vous pouvez causer des problèmes. Cisco prévoit de remplacer NTP version 3 par la version 4 afin de résoudre ce problème.
Si vous n'êtes pas au courant de ces problèmes, vous pouvez décider de bricoler manuellement avec cette valeur. Afin de migrer d'un périphérique à un autre, vous pouvez décider de copier l'ancienne configuration et de la coller sur le nouveau périphérique. Malheureusement, comme la commande ntp clock-Period apparaît dans les commandes running-config et startup-config, la période d'horloge NTP est collée sur le nouveau périphérique. Lorsque cela se produit, NTP sur le nouveau client devient toujours désynchronisé avec le serveur avec une valeur de dispersion homologue élevée.
À la place, effacez la période d'horloge NTP avec la commande no ntp clock-Period, puis enregistrez la configuration. Le routeur finit par calculer une période d’horloge appropriée à lui-même.
La commande ntp clock-Period n'est plus disponible dans la version 15.0 ou ultérieure du logiciel Cisco IOS ; l'analyseur rejette maintenant la commande avec l'erreur :
"%NTP: This configuration command is deprecated."
Par conséquent, vous n'êtes pas autorisé à configurer manuellement la période d'horloge et la période d'horloge n'est pas autorisée dans la configuration en cours. Puisque l'analyseur rejette la commande si elle se trouvait dans la configuration de démarrage (dans les versions antérieures de Cisco IOS telles que 12.4), l'analyseur rejette la commande lorsqu'il copie la configuration de démarrage dans la configuration en cours lors de l'amorçage.
La nouvelle commande de remplacement est ntp clear drift.
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
17-Aug-2013 |
Première publication |
Commentaires