Ce document décrit comment vérifier, dépanner et résoudre les problèmes NTP (Network Time Protocol) dans un fabric Cisco ACI. Il couvre le modèle de stratégie NTP, la vérification de la configuration, les commandes de vérification opérationnelle, un workflow de triage pour les symptômes NTP courants et des scénarios de dépannage détaillés.
Le contenu de ce document a été extrait du guide Troubleshoot ACI Management and Core Services — Pod Policies, du guide Cisco APIC Basic Configuration Guide, du chapitre Release 6.1(x) — Provisioning Core ACI Fabric Services et du guide de conception Cisco ACI.
La synchronisation temporelle est une fonctionnalité essentielle d'un fabric ACI dont dépendent les tâches de surveillance, d'exploitation et de dépannage. La synchronisation d'horloge garantit une analyse correcte des flux de trafic, la corrélation des horodatages de débogage et de panne sur plusieurs noeuds de fabric et l'utilisation complète de la fonctionnalité de compteur atomique dont dépendent les scores d'intégrité des applications. Une configuration NTP inexistante ou incorrecte ne déclenche pas nécessairement une panne ou un faible score d'intégrité. Il est donc important de configurer la synchronisation de l'heure au début du déploiement du fabric.
Le protocole NTP de l'ACI est géré via une chaîne de quatre objets de stratégie :
datetimePol) : définit la configuration NTP, notamment l'état administratif, l'état d'authentification, l'état du serveur et le mode maître. Situé sous Fabric > Fabric Policies > Policies > Pod > Date and Time.datetimeNtpProv) : définit les entrées de serveur NTP individuelles (fournisseurs) dans une politique de date et d'heure, y compris l'IP/FQDN du serveur, la sélection d'EPG de gestion (hors bande ou en bande), l'indicateur préféré et les intervalles d'interrogation.fabricPodPGrp) — référence la politique Date et heure avec d'autres politiques au niveau pod (BGP RR, SNMP, etc.). Situé sous Fabric > Fabric Policies > Pods > Policy Groups.fabricPodP) : associe un groupe de politiques de pod à un sélecteur de pod. Situé sous Fabric > Fabric Policies > Pods > Profiles.Les quatre liaisons de cette chaîne doivent être configurées pour que le protocole NTP soit appliqué aux noeuds du fabric. Si une liaison est rompue, la configuration du fournisseur NTP ne sera pas envoyée aux commutateurs.
L'ACI prend en charge trois schémas d'authentification NTP : MD5, SHA-1 et AES128-CMAC. AES128-CMAC a été introduit dans APIC version 6.1(1) et est le schéma recommandé, car MD5 est considéré comme faible et non sécurisé. Lorsque le mode FIPS est activé, seuls AES128-CMAC et SHA-1 sont pris en charge.
Les commutateurs Leaf ACI peuvent servir de serveurs NTP pour les clients en aval (par exemple, les serveurs connectés au fabric). Cette fonctionnalité est désactivée par défaut et doit être explicitement activée via l'option État du serveur dans la stratégie Date et heure. Lorsque cette option est activée, les clients peuvent utiliser l'adresse IP intrabande, hors bande, de domaine de pont SVI ou L3Out du commutateur Leaf comme adresse de serveur NTP.
Avant de dépanner l'état opérationnel NTP, vérifiez que la chaîne de configuration est terminée. La mauvaise configuration est la cause principale des problèmes NTP dans l'ACI.
Accédez à Tenants > mgmt > Node Management Addresses (pour l'affectation statique) ou Node Management EPGs (pour les groupes de connectivité).
Vérifiez qu'une adresse IP de gestion est attribuée à chaque APIC et noeud de commutateur. Les noeuds sans adresse de gestion ne peuvent pas communiquer avec le serveur NTP.
Vous pouvez également interroger l'API :
apic1# moquery -c mgmtRsOoBStNode
Accédez à Fabric > Fabric Policies > Policies > Pod > Date and Time > [Your Policy].

Vérifiez qu'au moins un fournisseur NTP (serveur) est configuré. S'il existe plusieurs fournisseurs, marquez au moins l'un d'entre eux comme Preferred.
Vérifiez le fournisseur NTP via l'API :
apic1# moquery -c datetimeNtpProv # datetimeNtpProv dn : uni/fabric/time-NTP-Policy/ntpprov-10.1.1.100 name : 10.1.1.100 preferred : yes <--- at least one should be "yes" epgDn : uni/tn-mgmt/mgmtp-default/oob-default <--- management EPG minPoll : 4 maxPoll : 6 keyId : 0
Accédez à Fabric > Fabric Policies > Pods > Policy Groups > [Your Pod Policy Group].

Confirmez que le champ Politique de date et d'heure fait référence à la politique de date et d'heure correcte.
apic1# moquery -c fabricPodPGrp -f 'fabricPodPGrp.name=="default"'
Recherchez l'attribut datetimePolName ou la relation fabricRsTimePol associée.
Accédez à Fabric > Fabric Policies > Pods > Profiles > [Your Pod Profile].

Vérifiez que le champ Groupe de stratégies de fabric fait référence au groupe de stratégies de pod approprié.
Accédez à System > System Settings > Date and Time.

Vérifiez que le format d'affichage (local ou UTC) et le fuseau horaire sont définis comme prévu. Ce paramètre est une stratégie de format de date et d'heure par défaut distincte qui ne peut pas être supprimée ou dupliquée.
Après avoir vérifié que la chaîne de configuration est correcte, utilisez les commandes suivantes pour vérifier que le protocole NTP fonctionne au moment de l'exécution.
Cette commande affiche l'état de synchronisation NTP sur tous les APIC. Le symbole * indique que le serveur est sélectionné pour la synchronisation.
apic1# show ntpq nodeid remote refid st t when poll reach auth delay offset jitter ------ - ------------------------------ ------------------------------ -------- -- -------- -------- -------- ---- -------- -------- -------- 1 * ntp.example.com .GPS. 1 u 20 64 377 none 0.213 +0.102 0.005 2 * ntp.example.com .GPS. 1 u 6 64 377 none 0.196 +0.007 0.004 3 * ntp.example.com .GPS. 1 u 27 64 377 none 0.216 -0.008 0.006
A quoi ressemble le bien :
* (sélectionné pour la synchronisation) à côté du serveur distant.reach est de 377 (octal), ce qui indique que les 8 derniers sondages ont tous réussi.st (strate) est compris entre 1 et 15. La strate 16 signifie que le serveur n'est pas synchronisé.le décalage est faible (généralement inférieur à 100 ms pour un environnement sain).A quoi ressemble le mauvais :
* en regard d'un serveur : aucun serveur n'est sélectionné pour la synchronisation.reach is 0 — aucune réponse NTP n'a été reçue.st is 16 — le serveur NTP n'est pas synchronisé avec sa source de temps en amont.offset est extrêmement grand (des milliers de millisecondes) — l'horloge est considérablement déviée.apic1# show clock Time : 11:24:18.391 UTC-04:00 Tue Apr 07 2026
Vérifiez que l'heure est correcte. Comparer avec le temps prévu pour détecter la dérive d'horloge.
apic1# bash admin@apic1:~> date Tue Apr 7 11:24:45 EDT 2026
Vérifiez que le fournisseur NTP a été envoyé au commutateur.
leaf1# show ntp peers ----------------------------------------------------------------------------- Peer IP Address Serv/Peer Prefer KeyId Vrf ----------------------------------------------------------------------------- 10.1.1.100 Server yes None management
A quoi ressemble le bien : L'adresse IP ou le nom d'hôte du serveur NTP apparaît avec Serv/Peer = Server et le VRF correct (généralement la gestion pour OOB).
A quoi ressemble le mauvais : Aucun homologue répertorié ou l'adresse IP du serveur NTP ne correspond pas au fournisseur configuré. Cela indique généralement que la politique de date et d'heure n'a pas été appliquée via la chaîne Groupe de politiques de pod / Profil de pod.
Vérifiez que le serveur NTP est sélectionné pour la synchronisation.
leaf1# show ntp peer-status
Total peers : 1
* - selected for sync, + - peer mode(active),
- - peer mode(passive), = - polled in client mode
remote local st poll reach delay vrf
--------------------------------------------------------------------------------
*10.1.1.100 0.0.0.0 1 64 377 0.000 management
Le caractère * est essentiel : il confirme que le serveur NTP est utilisé pour la synchronisation.
A quoi ressemble le mauvais :
* à côté du serveur — le commutateur n'est pas synchronisé avec le serveur.reach is 0 — aucune réponse NTP n'a été reçue. Cela indique un problème d'accessibilité.st is 16 — le serveur NTP n'est pas synchronisé et ne peut pas fournir d'heure valide.Vérifiez l'échange de paquets NTP pour confirmer l'accessibilité. Remplacez l'adresse IP par l'adresse du fournisseur NTP du commutateur concerné.
leaf1# show ntp statistics peer ipaddr 10.1.1.100 ... packets sent: 9256 packets received: 9256 ...
A quoi ressemble le bien : les paquets envoyés et les paquets reçus sont à peu près égaux et augmentent.
A quoi ressemble le mauvais : Les paquets envoyés sont incrémentés, mais les paquets reçus sont de 0 ou à peine incrémentés : les réponses NTP n'atteignent pas le commutateur.
leaf1# show clock 11:24:24.121066 EDT Tue Apr 07 2026
Accédez à Fabric > Fabric Policies > Policies > Pod > Date and Time > [Your Policy] > [NTP Provider].
La colonne Sync Status doit afficher Synchronced to Remote NTP Server pour tous les noeuds. La convergence de l'état de synchronisation après le déploiement initial peut prendre plusieurs minutes.
Interrogez la classe datetimeNtpq pour vérifier la synchronisation NTP sur tous les APIC :
apic1# moquery -c datetimeNtpq # datetimeNtpq dn : topology/pod-1/node-1/sys/ntpq-ntp.example.com remote : ntp.example.com tally : * <--- selected for sync stratum : 1 reach : 377 <--- all recent polls successful offset : +0.102 delay : 0.213 jitter : 0.005 refid : .GPS.
Utilisez cet arbre de décision lorsqu'un problème NTP est signalé sur un noeud ACI.
Connectez-vous au commutateur concerné et exécutez :
leaf1# show ntp peers
leaf1# show ntp peer-status
* présent → NTP est en cours de synchronisation. Si l'heure semble toujours incorrecte, passez au Scénario 5 : Décalage important / dérive d'horloge.* présent → passez à l'étape 3.Vérifiez la colonne reach dans show ntp peer-status.
reach = 0 → aucune réponse du serveur NTP. Accédez au scénario 2 : Serveur NTP inaccessible.atteignez > 0 mais aucune réponse * → n'est arrivée, mais la synchronisation n'est pas établie. Vérifier la strate : passez à l'étape 4.Symptôme : show ntp peers on the switch ne renvoie aucune entrée.
Vérification de la configuration :
Cause première : L'un des quatre liens de la chaîne de stratégie (Stratégie de date et d'heure → Fournisseur NTP → Groupe de stratégies Pod → Profil Pod) est rompu. La cause la plus fréquente est le fait que le groupe de politiques de pod n'est pas associé au profil de pod ou que la politique de date et d'heure n'est pas sélectionnée dans le groupe de politiques de pod.
Solution : Complétez le maillon manquant dans la chaîne des stratégies. Assurez-vous que le profil de pod du pod concerné fait référence à un groupe de stratégies de pod qui contient la stratégie de date et d'heure correcte. Une fois appliquée, la configuration du fournisseur NTP sera envoyée aux commutateurs dans quelques minutes.
Symptôme : show ntp peer-status indique reach = 0. show ntp statistics peer ipaddr 10.1.1.100 indique les paquets reçus = 0.
Vérification de la configuration : Vérifiez que le fournisseur NTP est associé au bon EPG de gestion (OOB ou intrabande). Si vous utilisez OOB, vérifiez que les contrats OOB autorisent le port UDP 123.
Contrôle opérationnel :
leaf1# ping 10.1.1.100 vrf management
leaf1# tcpdump -n -i eth0 dst port 123 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:49:01.431624 IP 10.1.20.23.123 > 10.1.1.100.123: NTPv4, Client, length 48 16:49:01.440303 IP 10.1.1.100.123 > 10.1.20.23.123: NTPv4, Server, length 48
Cause première : En général, l'un des éléments suivants :
Solution : Résolvez le problème d'accessibilité. Attribuez une adresse de gestion si elle est manquante, corrigez la passerelle par défaut, mettez à jour les règles de pare-feu ou corrigez la sélection de l'EPG de gestion sur le fournisseur NTP.
Symptôme : show ntp peer-status montre strate (st) = 16. Le commutateur ne se synchronisera pas avec un serveur strate 16.
Contrôle opérationnel : Connectez-vous au serveur NTP ou interrogez-le à partir d'un hôte externe pour vérifier qu'il est synchronisé avec sa propre source temporelle en amont.
Cause première : Le serveur NTP lui-même a perdu la synchronisation avec son horloge de référence en amont. Un serveur avec la strate 16 annonce qu'il n'a pas de source temporelle fiable.
Solution : Réparez le serveur NTP. Ceci se trouve en dehors du fabric ACI : vérifiez la configuration du serveur NTP et sa source temporelle en amont. Si le serveur NTP ne peut pas être réparé immédiatement, configurez un autre fournisseur NTP dans la stratégie Date et heure.
Symptôme : show ntp peer-status affiche reach > 0 et stratum est valide, mais no * s'affiche. Le serveur NTP répond, mais le commutateur n'accepte pas la réponse.
Vérification de la configuration :
Cause première : La clé d'authentification, l'algorithme ou l'ID de clé ne correspond pas entre l'ACI et le serveur NTP, ce qui entraîne le rejet de la réponse NTP comme non authentifiée par le commutateur.
Solution : Alignez la configuration de l’authentification. Assurez-vous que l'ID de clé, la valeur de clé et l'algorithme sont configurés de la même manière sur l'ACI et le serveur NTP. AES128-CMAC est recommandé pour les versions APIC 6.1(1) et ultérieures.
Symptôme : Le commutateur semble synchronisé (* présent, portée = 377), mais la valeur de décalage dans show ntp peer-status ou dans show ntpq est très grande (des centaines ou des milliers de millisecondes), ou l'horloge est visiblement incorrecte.
Contrôle opérationnel :
apic1# show ntpq
Vérifiez la colonne offset. Un décalage sain est généralement inférieur à 100 ms.
Cause première : L'horloge a dévié de manière significative avant l'établissement de la synchronisation NTP, ou l'horloge matérielle (RTC) a été réinitialisée lors d'un redémarrage (par exemple, en raison d'une batterie CMOS morte). Le NTP corrige l'horloge progressivement par pivotement, ce qui peut prendre du temps pour les grands décalages.
Solution : Si le décalage est très grand et que le protocole NTP est en cours de synchronisation, attendez que l'horloge converge. Le protocole NTP fait pivoter l'horloge progressivement : les décalages importants peuvent prendre des heures pour être entièrement corrigés. Si le décalage ne diminue pas, vérifiez que le serveur NTP fournit l'heure exacte. Si le problème se reproduit après chaque redémarrage, examinez l'horloge matérielle (pile RTC/CMOS) sur le noeud affecté.
Symptôme : Des erreurs sont générées sur un APIC de secours lié à NTP ou à la politique de surveillance lorsque NTP est configuré pour la gestion intrabande.
Cause première : Lorsqu’une stratégie NTP est appliquée pour la gestion intrabande, le contrôleur APIC de secours requiert également une configuration intrabande. Sans elle, les défauts sont augmentés.
Solution : Configurez également la gestion intrabande pour le contrôleur APIC de secours. Cela efface les défauts.
Symptôme : Une erreur IP dupliquée est déclenchée après l'ajout de fournisseurs NTP.
Cause première : Un nom de domaine complet a été ajouté en tant que fournisseur NTP, puis l'adresse IP résolue de ce nom de domaine complet a été ajoutée en tant que deuxième fournisseur NTP. L'ACI détecte le doublon.
Solution : Supprimez le dernier fournisseur dupliqué ajouté (l'entrée d'adresse IP si le nom de domaine complet a été ajouté en premier, ou vice versa). Utilisez une seule entrée par serveur NTP : soit le nom de domaine complet (FQDN), soit l'adresse IP, et non les deux.
Symptôme : Le fournisseur NTP configuré avec un nom d'hôte n'est pas résolu. show ntp peers n'affiche pas l'adresse IP attendue ou NTP ne se synchronise pas.
Vérification de la configuration :
Cause première : Le serveur DNS n'est pas accessible ou n'est pas configuré, ce qui entraîne l'échec de la résolution du nom d'hôte pour le fournisseur NTP.
Solution : Configurez la stratégie de service DNS, assurez l'accessibilité DNS et appliquez l'étiquette DNS correcte. Vous pouvez également utiliser l'adresse IP du serveur NTP au lieu du nom d'hôte.
Les conditions suivantes sont liées au protocole NTP et peuvent générer des défaillances dans l'ACI :
Envisagez de transférer le problème au TAC Cisco si :
show ntp peer-status montre un comportement inattendu tel que la strate persistante 16 sur un serveur qui est confirmé synchronisé en externe.Lorsque vous faites appel au TAC, fournissez les données suivantes :
show ntpq de tous les APIC.show ntp peer, show ntp peer-status, show ntp statistics peer ipaddr <IP> et show clock de tous les commutateurs affectés.moquery -c datetimePol, moquery -c datetimeNtpProv, et moquery -c datetimeNtpq de l'APIC.| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
07-Apr-2026
|
Première publication |