In dit document wordt beschreven hoe problemen met het Network Time Protocol (NTP) in een Cisco ACI-fabric kunnen worden geverifieerd, opgelost en opgelost. Het omvat het NTP-beleidsmodel, configuratieverificatie, operationele verificatieopdrachten, een triage-workflow voor veelvoorkomende NTP-symptomen en gedetailleerde scenario's voor probleemoplossing.
Het materiaal uit dit document is afkomstig uit de handleiding Problemen oplossen met ACI-beheer en kernservices — Pod Policies, de APIC Basic Configuration Guide van Cisco, versie 6.1 (x) — Provisioning Core ACI Fabric Services, en het ACI Design Guide van Cisco.
Tijdsynchronisatie is een cruciale mogelijkheid in een ACI-fabric waarvan bewakings-, operationele en probleemoplossende taken afhankelijk zijn. Kloksynchronisatie zorgt voor een goede analyse van verkeersstromen, correlatie van foutopsporing en fouttijdstempels over meerdere fabric-knooppunten en volledig gebruik van de atomaire tellermogelijkheden waarvan de gezondheidsscores van toepassingen afhankelijk zijn. Niet-bestaande of onjuiste NTP-configuratie leidt niet noodzakelijkerwijs tot een fout of een lage gezondheidsscore, dus het is belangrijk om tijdsynchronisatie vroeg in de fabrikantimplementatie te configureren.
NTP in ACI wordt beheerd via een keten van vier beleidsobjecten:
datetimePol) — definieert de NTP-configuratie, inclusief de beheerdersstatus, de verificatiestatus, de serverstatus en de hoofdmodus. U bevindt zich onder Verbinding > Verbindingsbeleid > Beleid > Pod > Datum en tijd.datetimeNtpProv) — definieert afzonderlijke NTP-serververmeldingen (providers) binnen een datum- en tijdbeleid, inclusief de IP/FQDN-server, EPG-beheerselectie (out-of-band of in-band), voorkeursvlag en polling-intervallen.fabricPodPGrp) — verwijst naar het datum- en tijdbeleid en andere beleidsregels op pod-niveau (BGP RR, SNMP, enz.). U vindt deze onder Verbinding > Verbindingsbeleid > Pods > Beleidsgroepen.fabricPodP) — koppelt een Pod Policy Group aan een pod-selector. Deze bevindt zich onder Verbinding > Verbindingsbeleid > Pods > Profielen.Alle vier de schakels in deze keten moeten worden geconfigureerd zodat NTP op de fabric-nodes kan worden toegepast. Als een koppeling verbroken is, wordt de NTP-providerconfiguratie niet naar de switches geduwd.
ACI ondersteunt drie NTP-verificatieschema's: MD5, SHA-1 en AES128-CMAC. AES128-CMAC werd geïntroduceerd in APIC versie 6.1(1) en is het aanbevolen schema, aangezien MD5 als zwak en onveilig wordt beschouwd. Als de FIPS-modus is ingeschakeld, worden alleen AES128-CMAC en SHA-1 ondersteund.
ACI leaf switches kunnen fungeren als NTP-servers voor downstream clients (bijvoorbeeld servers die zijn aangesloten op de fabric). Deze functie is standaard uitgeschakeld en moet expliciet zijn ingeschakeld via de optie Serverstatus in het beleid Datum en tijd. Wanneer ingeschakeld, kunnen clients het in-band, out-of-band, bridge domain SVI of L3Out IP-adres van leaf switch gebruiken als het NTP-serveradres.
Voordat u problemen met de operationele status van NTP oplost, moet u controleren of de configuratieketen is voltooid. Misconfiguratie is de meest voorkomende oorzaak van NTP-problemen in ACI.
Navigeer naar Tenants > Management > Node Management Addresses (voor statische toewijzing) of Node Management EPG's (voor connectiviteitsgroepen).
Bevestig dat aan elk APIC- en switch-knooppunt een IP-beheeradres is toegewezen. Nodes zonder beheeradressen kunnen niet communiceren met de NTP-server.
U kunt ook de API opvragen:
apic1# moquery -c mgmtRsOoBStNode
Navigeer naar Fabric > Fabric Policies > Policies > Pod > Date and Time > [Uw beleid].

Controleer of ten minste één NTP-provider (server) is geconfigureerd. Als er meerdere providers bestaan, markeert u ten minste één als voorkeursoptie.
Controleer de NTP-provider via de 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
Navigeer naar Fabric > Fabric Policies > Pods > Policy Groups > [Your Pod Policy Group].

Bevestig dat het veld Datumtijdbeleid verwijst naar het juiste datum- en tijdbeleid.
apic1# moquery -c fabricPodPGrp -f 'fabricPodPGrp.name=="default"'
Zoek naar het attribuut datetimePolName of de bijbehorende fabricRsTimePol-relatie.
Navigeer naar Fabric > Fabric Policies > Pods > Profiles > [Uw Pod-profiel].

Bevestig de verwijzingen in het veld Verbindingsbeleidsgroep naar de juiste POD-beleidsgroep.
Navigeer naar Systeem > Systeeminstellingen > Datum en tijd.

Bevestig dat het weergaveformaat (lokaal of UTC) en de tijdzone zijn ingesteld zoals verwacht. Deze instelling is een afzonderlijk standaard beleid voor de datumtijdnotatie dat niet kan worden verwijderd of gedupliceerd.
Nadat u hebt bevestigd dat de configuratieketen correct is, gebruikt u de volgende opdrachten om te controleren of NTP tijdens runtime werkt.
Deze opdracht toont de NTP-synchronisatiestatus voor alle APIC's. Het symbool * geeft aan dat de server is geselecteerd voor synchronisatie.
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
Hoe ziet goed eruit:
* (geselecteerd voor synchronisatie) naast de externe server weergegeven.reach is 377 (octaal), wat aangeeft dat de laatste 8 enquêtes allemaal succesvol waren.St (stratum) ligt tussen 1-15. Stratum 16 betekent dat de server niet gesynchroniseerd is.De offset is laag (meestal minder dan 100 ms voor een gezonde omgeving).Hoe ziet slecht eruit:
* naast elke server — er is geen server geselecteerd voor synchronisatie.bereik is 0 — er zijn geen NTP-antwoorden ontvangen.st is 16 - de NTP-server is niet gesynchroniseerd met de upstream-tijdbron.Offset is extreem groot (duizenden milliseconden) - de klok is aanzienlijk verschoven.apic1# show clock Time : 11:24:18.391 UTC-04:00 Tue Apr 07 2026
Bevestig dat de tijd nauwkeurig is. Vergelijk met de verwachte tijd om klokdrift te detecteren.
apic1# bash admin@apic1:~> date Tue Apr 7 11:24:45 EDT 2026
Controleer of de NTP-provider naar de switch is geduwd.
leaf1# show ntp peers ----------------------------------------------------------------------------- Peer IP Address Serv/Peer Prefer KeyId Vrf ----------------------------------------------------------------------------- 10.1.1.100 Server yes None management
Hoe ziet goed eruit: De IP- of hostnaam van de NTP-server wordt weergegeven met Serv/Peer = Server en de juiste VRF (meestal beheer voor OOB).
Hoe slecht ziet eruit: Geen peers vermeld, of de NTP-server IP komt niet overeen met de geconfigureerde provider. Dit geeft meestal aan dat het datum- en tijdbeleid niet is toegepast via de pod-beleidsgroep / pod-profielketen.
Controleer of de NTP-server is geselecteerd voor synchronisatie.
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
Het * teken is essentieel — het bevestigt dat de NTP-server wordt gebruikt voor synchronisatie.
Hoe ziet slecht eruit:
* naast de server — de switch synchroniseert niet met de server.bereik is 0 — er zijn geen NTP-antwoorden ontvangen. Dit duidt op een probleem met bereikbaarheid.st is 16 — de NTP-server is niet gesynchroniseerd en kan geen geldige tijd opgeven.Verifieer de NTP-pakketuitwisseling om de bereikbaarheid te bevestigen. Vervang het IP-adres door het NTP-provideradres voor de betreffende switch.
leaf1# show ntp statistics peer ipaddr 10.1.1.100 ... packets sent: 9256 packets received: 9256 ...
Hoe goed ziet eruit: verzonden pakketten en ontvangen pakketten zijn ongeveer gelijk en nemen toe.
Hoe slecht ziet eruit: verzonden pakketten nemen toe, maar ontvangen pakketten nemen 0 of nauwelijks toe - NTP-reacties bereiken de switch niet.
leaf1# show clock 11:24:24.121066 EDT Tue Apr 07 2026
Navigeer naar Fabric > Fabric Policies > Policies > Pod > Date and Time > [Uw beleid] > [NTP-provider].
De kolom Synchronisatiestatus moet Gesynchroniseerd met externe NTP-server voor alle knooppunten weergeven. Het kan enkele minuten duren voordat de synchronisatiestatus is geconvergeerd na de eerste implementatie.
Vraag de klasse datetimeNtpq om NTP-synchronisatie voor alle APIC's te controleren:
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.
Gebruik deze beslisboom wanneer een NTP-probleem wordt gemeld op een ACI-node.
Meld u aan bij de betreffende switch en voer het volgende uit:
leaf1# show ntp peers
leaf1# show ntp peer-status
* present → NTP is syncing. Als de tijd nog steeds verkeerd lijkt, gaat u naar Scenario 5: Grote offset / klokdrift.* aanwezig → doorgaan naar Stap 3.Controleer de kolom bereik in NTP-peer-status weergeven.
bereik = 0 → geen antwoorden van de NTP-server. Ga naar Scenario 2: NTP-server onbereikbaar.REACH > 0 maar er komen geen * → antwoorden aan, maar de synchronisatie is niet tot stand gebracht. Controleer stratum — ga naar stap 4.Symptoom: toon ntp-peers op de switch geeft geen items terug.
Configuratiecontrole:
Hoofdoorzaak: een van de vier links in de beleidsketen (Datum- en tijdbeleid → NTP Provider → Pod Policy Group → Pod Profile) is verbroken. De meest voorkomende oorzaak is dat de POD-beleidsgroep niet is gekoppeld aan het POD-profiel of dat het beleid Datum en tijd niet is geselecteerd in de POD-beleidsgroep.
Oplossing: Voltooi de ontbrekende schakel in de beleidsketen. Zorg ervoor dat het pod-profiel voor de betreffende pod verwijst naar een pod-beleidsgroep die het juiste datum- en tijdbeleid bevat. Na toepassing wordt de NTP-providerconfiguratie binnen enkele minuten naar de switches geduwd.
Symptoom: toon ntp peer-status toont bereik = 0. toon ntp statistieken peer ipaddr 10.1.1.100 toont ontvangen pakketten = 0.
Configuratiecontrole: Controleer of de NTP-provider is gekoppeld aan het juiste EPG-beheer (OOB of in-band). Als u OOB gebruikt, controleert u of de OOB-contracten UDP-poort 123 toestaan.
Operationele controle:
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
Hoofdoorzaak: Doorgaans een van de volgende:
Oplossing: het probleem van bereikbaarheid oplossen. Wijs een beheeradres toe als dit ontbreekt, repareer de standaardgateway, werk firewallregels bij of corrigeer de EPG-beheerselectie op de NTP-provider.
Symptoom: toon ntp peer-status toont stratum (st) = 16. De switch wordt niet gesynchroniseerd met een stratum 16-server.
Operationele controle: Meld u aan bij de NTP-server of vraag deze op van een externe host om te controleren of deze is gesynchroniseerd met zijn eigen upstream-tijdbron.
Hoofdoorzaak: De NTP-server zelf heeft de synchronisatie met de upstream referentieklok verloren. Een server met stratum 16 adverteert dat deze geen betrouwbare tijdbron heeft.
Oplossing: de NTP-server repareren. Dit bevindt zich buiten de ACI-structuur — controleer de NTP-serverconfiguratie en de upstream-tijdbron. Als de NTP-server niet onmiddellijk kan worden hersteld, configureert u een alternatieve NTP-provider in het beleid Datum en tijd.
Symptoom: NTP-peer-status tonen toont bereik > 0 en stratum is geldig, maar er wordt geen * weergegeven. De NTP-server reageert, maar de switch accepteert het antwoord niet.
Configuratiecontrole:
Hoofdoorzaak: de verificatiesleutel, het algoritme of de sleutel-ID is niet goed afgestemd tussen ACI en de NTP-server, waardoor de switch de NTP-reactie afwijst als niet-geverifieerd.
Oplossing: de verificatieconfiguratie uitlijnen. Zorg ervoor dat dezelfde sleutel-ID, sleutelwaarde en algoritme zijn geconfigureerd op zowel ACI als de NTP-server. AES128-CMAC wordt aanbevolen voor APIC-release 6.1(1) en hoger.
Symptoom: De switch lijkt gesynchroniseerd (* aanwezig, bereik = 377), maar de offset waarde in tonen ntp peer-status of tonen ntpq is erg groot (honderdduizenden milliseconden), of de klok is zichtbaar fout.
Operationele controle:
apic1# show ntpq
Controleer de kolom offset. Een gezonde offset is meestal minder dan 100 ms.
Hoofdoorzaak: de klok is aanzienlijk afgeweken voordat NTP-synchronisatie werd ingesteld of de hardwareklok (RTC) werd gereset tijdens een herstart (bijv. vanwege een lege CMOS-batterij). NTP corrigeert de klok geleidelijk door te draaien, wat tijd kan kosten voor grote offsets.
Oplossing: Als de offset erg groot is en NTP actief synchroniseert, wacht dan tot de klok convergeert. NTP schakelt de klok geleidelijk - grote offsets kunnen uren duren om volledig te corrigeren. Als de offset niet afneemt, controleert u of de NTP-server de juiste tijd levert. Als het probleem zich na elke herstart opnieuw voordoet, onderzoekt u de hardwareklok (RTC / CMOS-batterij) op de getroffen node.
Symptoom: Fouten worden gegenereerd op een stand-by APIC met betrekking tot NTP of monitoringbeleid wanneer NTP is geconfigureerd voor in-band beheer.
Hoofdoorzaak: wanneer een NTP-beleid wordt toegepast voor in-band beheer, vereist de stand-by APIC ook in-band configuratie. Zonder dat worden de fouten gemaakt.
Oplossing: Configureer ook in-band beheer voor de APIC die stand-by staat. Hiermee worden de fouten opgeruimd.
Symptoom: Een duplicaat IP-fout wordt verhoogd na het toevoegen van NTP-providers.
Root Cause: Een FQDN werd toegevoegd als een NTP-provider, en vervolgens het opgeloste IP-adres van die FQDN werd toegevoegd als een tweede NTP-provider. ACI detecteert het duplicaat.
Oplossing: Verwijder de meest recent toegevoegde duplicaatprovider (het invoeren van het IP-adres als de FQDN eerst is toegevoegd, of vice versa). Gebruik slechts één invoer per NTP-server: FQDN- of IP-adres, niet beide.
Symptoom: NTP-provider geconfigureerd met een hostnaam lost niet op. toon ntp-peers geeft het verwachte IP-adres niet weer of NTP synchroniseert niet.
Configuratiecontrole:
Hoofdoorzaak: de DNS-server kan niet worden bereikt of is niet geconfigureerd, waardoor de hostnaamresolutie voor de NTP-provider mislukt.
Oplossing: Configureer het DNS-servicebeleid, zorg voor DNS-bereikbaarheid en pas het juiste DNS-label toe. U kunt ook het IP-adres van de NTP-server gebruiken in plaats van de hostnaam.
De volgende zijn NTP-gerelateerde aandoeningen die fouten in ACI kunnen genereren:
Overweeg te escaleren naar Cisco TAC als:
ntp peer-status uitvoer toont onverwacht gedrag zoals persistent stratum 16 op een server die extern bevestigd en gesynchroniseerd is.Verstrek de volgende gegevens wanneer TAC wordt toegepast:
show ntpq van alle APIC's.tonen ntp peers, tonen ntp peer-status, tonen ntp statistieken peer ipaddr <IP>, en tonen klok van alle betrokken switches.moquery -c datetimePol, moquery -c datetimeNtpProv, en moquery -c datetimeNtpq van de APIC.| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
07-Apr-2026
|
Eerste vrijgave |