Problemen met Network Time Protocol oplossen en debuggen
Downloadopties
Inclusief taalgebruik
De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Over deze vertaling
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Inhoud
Inleiding
Dit document beschrijft hoe u problemen met Network Time Protocol (NTP) kunt oplossen bijdebugopdrachten en deshow ntpopdracht.
Voorwaarden
Vereisten
Er zijn geen specifieke vereisten van toepassing op dit document.
Gebruikte componenten
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
NTP-opdrachten weergeven
Alvorens u de oorzaak van problemen NTP bekijkt, moet u het gebruik van en de output van deze bevelen begrijpen:
- toon ntp vereniging
- ntp-associatiedetail tonen
- ntp-status tonen
Opmerking: gebruik de Opdrachtzoekfunctie om meer informatie te verkrijgen over de opdrachten die in deze sectie worden gebruikt. Alleen geregistreerde Cisco-gebruikers kunnen toegang krijgen tot interne tools en informatie.
Opmerking: het hulpprogramma Output Interpreter ondersteunt bepaalde showopdrachten. Alleen geregistreerde Cisco-gebruikers kunnen toegang krijgen tot interne tools en informatie.
Opdracht NTP-associatie tonen
Een NTP-associatie kan zijn:
- een peer-associatie (het ene systeem is bereid om te synchroniseren met het andere systeem, of het andere systeem te laten synchroniseren met het andere systeem.)
- een serverkoppeling (slechts één systeem synchroniseert met het andere systeem en niet andersom).
Dit is een voorbeeld van output van het show ntp associatiebevel:
CLA_PASA#sh ntp association
address ref clock st when poll reach delay offset disp
~10.127.7.1 10.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 10.79.127.250 4 7 256 377 0.8 -0.29 0.2
*~10.50.36.42 10.79.127.250 4 188 256 377 0.7 -0.17 0.3
+~10.50.38.50 10.79.127.250 4 42 256 377 0.9 1.02 0.4
+~10.50.36.50 10.79.127.250 4 20 256 377 0.7 0.87 0.5
* primary (synced), # primary (unsynced), + selected, - candidate, ~ configured
| Begrip | Toelichting |
|---|---|
| Tekens voor het adres hebben de volgende definities:
|
|
| adres |
Dit is het IP-adres van de peer. In het voorbeeld wordt bij de eerste vermelding 127.127.7.1 vermeld. Dit geeft aan dat de lokale machine gesynchroniseerd is met zichzelf. Over het algemeen, slechts primaire syncs NTP met zich. |
| refklok |
Dit is het adres van de referentieklok voor de peer. In het voorbeeld hebben de eerste zes peers/servers een privaat IP als referentieklok, zodat hun basisstations waarschijnlijk routers, switches of servers zijn binnen het lokale netwerk. Voor de laatste vier inzendingen is de referentieklok een publiek IP, zodat hun voorverkiezingen waarschijnlijk een openbare tijdbron zijn. |
| st |
NTP gebruikt het concept van een stratum om te beschrijven hoe ver weg (in NTP-hop) een machine van een gezaghebbende tijdbron is. Bijvoorbeeld, een stratum 1 tijdserver heeft een radio of atoomklok direct aan het bevestigd. Het stuurt zijn tijd naar een stratum 2 tijdserver via NTP, en zo verder tot stratum 16. Een machine die NTP in werking stelt kiest automatisch de machine met het laagste stratumaantal waarmee het kan communiceren en NTP als zijn tijdbron gebruikt. |
| wanneer |
De tijd sinds het laatste NTP-pakket is ontvangen van een peer wordt in seconden gerapporteerd. Deze waarde moet lager zijn dan het opiniepeilingsinterval. |
| enquête |
Het pollinginterval wordt in seconden gerapporteerd. Het interval begint gewoonlijk met een minimum van 64 tweede opiniepeilingsintervallen. De RFC specificeert dat niet meer dan één NTP-transactie per minuut nodig is om twee machines te synchroniseren. Aangezien NTP stabiel wordt tussen een client en een server, kan het poll interval in kleine stappen van 64 seconden tot 1024 seconden toenemen en stabiliseert over het algemeen ergens tussen. Maar deze waarde verandert dynamisch, gebaseerd op de netwerkvoorwaarden tussen de client en de server en het verlies van NTP-pakketten. Als een server enige tijd onbereikbaar is, wordt het poll interval in stappen verhoogd naar 1024 seconden om netwerk overhead te verminderen. Het is niet mogelijk om het NTP poll interval op een router aan te passen, omdat intern door heuristische algoritmen wordt bepaald. |
| bereik |
Peer-bereikbaarheid is een bitstring die gerapporteerd wordt als een octale waarde. Dit veld toont aan of de laatste acht pakketten zijn ontvangen door het NTP-proces op de Cisco IOS®-software. De pakketten moeten worden ontvangen, verwerkt en aanvaard als geldig door het NTP-proces en niet alleen door de router of switch die de NTP IP-pakketten ontvangt. Reach gebruikt het poll interval voor een time-out om te beslissen of een pakket is ontvangen of niet. Het opiniepeilinterval is de tijd dat NTP wacht alvorens het concludeert dat een pakket werd verloren. De opiniepeiltijd kan voor verschillende peers verschillend zijn, zodat de tijd vóór bereik besluit dat een pakket werd verloren kan ook verschillend voor verschillende peers zijn. In het voorbeeld zijn er vier verschillende bereikwaarden:
Reach is een goede indicator van of NTP-pakketten worden verbroken vanwege een slechte link, CPU-problemen en andere intermitterende problemen. Unit Converter is een online unit converter voor deze en vele andere conversies. |
| vertraging |
De vertraging van de ronde reis naar peer wordt gemeld in milliseconden. Om de kloktijd nauwkeuriger in te stellen, wordt deze vertraging in aanmerking genomen wanneer de kloktijd is ingesteld. |
| neutraliseren |
Offset is het kloktijdverschil tussen de peers of tussen de primaire en de client. Deze waarde is de correctie die wordt toegepast op een cliëntklok om het te synchroniseren. Een positieve waarde geeft aan dat de kloktijd van de server hoger is. Een negatieve waarde geeft aan dat de klok van de client hoger is. |
| disp |
Dispersie, uitgedrukt in seconden, is het maximale kloktijdverschil dat ooit is waargenomen tussen de lokale kloktijd en de serverkloktijd. In het voorbeeld is de dispersie 0.3 voor de server 10.50.36.42, dus het maximale tijdverschil dat ooit lokaal is waargenomen tussen de lokale kloktijd en de serverkloktijd is 0.3 seconden. U kunt verwachten een hoge waarde te zien wanneer de klokken in eerste instantie sync zijn. Maar als de dispersie in andere tijden te hoog is, accepteert het NTP proces op de client geen NTP berichten van de server. Maximale dispersie is 16000; in het voorbeeld, dat is de dispersie voor servers 10.50.44.69 en 10.50.44.133, zodat de lokale client geen tijd van deze servers accepteert. Als het bereik nul is en de dispersie zeer hoog is, accepteert de client waarschijnlijk geen berichten van die server. Raadpleeg de tweede regel van het voorbeeld: address ref clock st when poll reach delay offset disp Ook al is de offset slechts -4,26, de dispersie is zeer hoog (misschien te wijten aan een gebeurtenis uit het verleden), en het bereik is nul, dus deze client accepteert geen tijd van deze server. |
ntp-associatiedetail tonen Opdracht
Dit is een voorbeeld van output van het bevel van het show ntp vereniging detail:
Router#sho ntp assoc detail
10.4.2.254 configured, our_primary, 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
Termen die reeds in de show up associatie sectie zijn gedefinieerd worden hier niet herhaald.
| Begrip |
Toelichting | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| geconfigureerd |
Deze NTP klokbron is geconfigureerd om een server te zijn. Deze waarde kan ook dynamisch zijn, waar de peer/server dynamisch werd ontdekt. |
|||||||||||||||||||||||||||
| our_primair |
De lokale client is gesynchroniseerd met deze peer. |
|||||||||||||||||||||||||||
| geselecteerd |
De peer/server is geselecteerd voor mogelijke synchronisatie, wanneer our_primary mislukt, of de client de sync verliest. |
|||||||||||||||||||||||||||
| verstandig |
Saniteitstests worden gebruikt om het NTP-pakket te testen dat van een server wordt ontvangen. Deze tests worden gespecificeerd in RFC 1305, Network Time Protocol (versie 3), specificatie, implementatie en analyse. De tests zijn:
Packet data is geldig als tests 1 tot en met 4 slagen. De gegevens worden dan gebruikt om offset, vertraging en dispersie te berekenen. Packet header is geldig als tests 5 tot 8 slagen. Alleen pakketten met een geldige header kunnen worden gebruikt om te bepalen of een peer kan worden geselecteerd voor synchronisatie. |
|||||||||||||||||||||||||||
| krankzinnig |
De controles van de gezondheid zijn mislukt, dus tijd vanaf de server wordt niet geaccepteerd. De server is niet gesynchroniseerd. |
|||||||||||||||||||||||||||
| valide |
De peer/server-tijd is geldig. De lokale client accepteert dit keer als deze peer de primaire wordt. |
|||||||||||||||||||||||||||
| invalide |
De peer/server tijd is ongeldig, en tijd kan niet worden geaccepteerd. |
|||||||||||||||||||||||||||
| referentie-id |
Elke peer/server krijgt een referentie-id (label) toegewezen. |
|||||||||||||||||||||||||||
| tijd |
De tijd is de laatste tijdzegel die van die peer/server wordt ontvangen. |
|||||||||||||||||||||||||||
| Onze modus/peer-modus |
Dit is de status van de lokale client/peer. |
|||||||||||||||||||||||||||
| onze enquête intvl/peer poll intvl |
Dit is het poll-interval van onze poll tot deze peer, of van de peer tot de lokale machine. |
|||||||||||||||||||||||||||
| wortelvertraging |
De vertraging van de wortel is de vertraging in milliseconden aan de wortel van de opstelling NTP. Stratum 1 klokken worden beschouwd als de wortel van een NTP opstelling/ontwerp. In het voorbeeld, kunnen alle drie servers de wortel zijn omdat zij bij stratum 1 zijn. |
|||||||||||||||||||||||||||
| wortelverspreiding |
Root dispersie is het maximale kloktijdverschil dat ooit werd waargenomen tussen de lokale kloktijd en de wortelkloktijd. Raadpleeg de uitleg van de disp onder Show up associatie voor meer details. |
|||||||||||||||||||||||||||
| sync-dist. |
Dit is een schatting van het maximumverschil tussen de tijd op stratum 0 bron en de tijd die door de cliënt wordt gemeten. Het bestaat uit componenten voor ronde reistijd, systeemprecisie, en klokdrift sinds de laatste daadwerkelijke gelezen van de stratumbron. In een grote NTP-installatie (NTP-servers in stratum 1 in het internet, met servers die brontijd in verschillende strata) met servers/clients in meerdere strata, moet NTP-synchronisatietopologie worden georganiseerd om de hoogste nauwkeurigheid te produceren, maar mag nooit een tijdsynchronisatielijn vormen. Een extra factor is dat elke toename in stratum een potentieel onbetrouwbare tijdserver betreft, die extra meetfouten introduceert. Het selectiealgoritme dat in NTP wordt gebruikt maakt gebruik van een variant van het Bellman-Ford gedistribueerde routingalgoritme om de minimum-gewicht-omspannende bomen te berekenen die geworteld zijn op de primaire servers. De metriek van de afstand die door het algoritme wordt gebruikt bestaat uit het stratum plus de synchronisatieafstand, die zelf uit de dispersie plus de helft van de absolute vertraging bestaat. Aldus, neemt de synchronisatiepad altijd het minimumaantal servers aan de wortel; de banden worden opgelost op basis van maximumfout. |
|||||||||||||||||||||||||||
| vertraging |
Dit is de ronde reisvertraging naar peer. |
|||||||||||||||||||||||||||
| correctheid |
Dit is de precisie van de peer kloktijd in Hz. |
|||||||||||||||||||||||||||
| versie |
Dit is het NTP-versienummer dat door de peer wordt gebruikt. |
|||||||||||||||||||||||||||
| org-tijd |
Dit is de tijdzegel van de NTP pakketmaker; met andere woorden, het is de peer tijdzegel toen het tot het pakket NTP leidde maar alvorens het het pakket naar de lokale cliënt verzond. |
|||||||||||||||||||||||||||
| rcv-tijd |
Dit is de tijdzegel toen de lokale client het bericht ontving. Het verschil tussen org-tijd en rcv-tijd is de offset voor deze peer. In het voorbeeld, primair 10.4.2.254 heeft deze tijden: org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012) Het verschil is de offset van 268,3044 msec. |
|||||||||||||||||||||||||||
| sluitingstijd |
Dit is de verzend tijdzegel voor het NTP pakket dat de lokale client naar deze peer/server verzendt. |
|||||||||||||||||||||||||||
| filtervertraging |
Dit is de ronde reisvertraging in milliseconden van elk monster. Een steekproef is het laatste ontvangen pakket NTP. In het voorbeeld heeft primair 10.4.2.254 de volgende waarden: filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72 Deze acht steekproeven corresponderen met de waarde van het bereik veld, dat toont of de lokale client de laatste acht NTP-pakketten heeft ontvangen. |
Opdracht NTP-status tonen
Dit is een voorbeeld van output van het bevel van de showntp 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
Termen die reeds zijn gedefinieerd in het vak associatie tonen of het gedeelte ntp associatie detail worden niet herhaald.
| Begrip | Toelichting |
|---|---|
| correctheid |
Nauwkeurigheid wordt automatisch bepaald en wordt gemeten als een vermogen van twee. In het voorbeeld betekent 2**18 2^(-18) of 3,8 microseconden. Het verlies aan synchronisatie tussen NTP-peers of tussen een primaire en client kan het gevolg zijn van verschillende oorzaken. NTP vermijdt synchronisatie met een machine waarvan de tijd op deze manieren dubbelzinnig kan zijn:
|
Probleemoplossing voor NTP met debuggen
Enkele van de meest voorkomende oorzaken van problemen met NTP zijn:
- NTP-pakketten worden niet ontvangen.
- NTP-pakketten worden ontvangen, maar niet verwerkt door het NTP-proces op Cisco IOS®.
- NTP-pakketten worden verwerkt, maar verkeerde factoren of pakketgegevens veroorzaken het verlies van synchronisatie.
- NTP-klokperiode is handmatig ingesteld.
Belangrijke debug commando's die helpen de oorzaak van deze problemen te isoleren, zijn:
- debug IP-pakketten <acl>
- debug ntp-pakketten
- debug ntp-geldigheid
- debug ntp sync
- debug van ntp-gebeurtenissen
De volgende secties illustreren het gebruik van debugs om deze gemeenschappelijke kwesties op te lossen.
Opmerking: gebruik de Opdrachtzoekfunctie om meer informatie te verkrijgen over de opdrachten die in deze sectie worden gebruikt. Alleen geregistreerde Cisco-gebruikers kunnen toegang krijgen tot interne tools en informatie.
Opmerking: raadpleeg Belangrijke informatie over debug-opdrachten voordat u debug-opdrachten gebruikt.
NTP-pakketten niet ontvangen
Gebruik de opdracht debug ip-pakket om te controleren of NTP-pakketten worden ontvangen en verzonden. Aangezien debug-uitvoer chattig kan zijn, kunt u debug-uitvoer beperken met het gebruik van ACL’s (Access Control Lists). NTP gebruikt UDP-poort (User Datagram Protocol) 123.
- ACL 101 maken:
access-list 101 permit udp any any eq 123
NTP-pakketten hebben doorgaans een bron- en doelpoort van 123, zodat dit helpt:
access-list 101 permit udp any eq 123 any
permit udp any eq 123 any eq 123
- Gebruik deze ACL om de uitvoer van de opdracht debug ip-pakket te beperken:
debug ip packet 101
- Als het probleem met bepaalde peers is, versmal dan ACL 101 tot die peers. Als de peer 172.16.1.1 is, wijzigt u ACL 101 in:
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
Deze voorbeelduitvoer geeft aan dat pakketten niet worden verzonden:
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
Zodra u bevestigt dat NTP-pakketten niet worden ontvangen, moet u:
- Controleer of NTP goed is geconfigureerd.
- Controleer of een ACL NTP-pakketten blokkeert.
- Controleer op routeringsproblemen met de bron of de bestemming-IP.
NTP-pakketten niet verwerkt
Met zowel debug ip pakket als debug ntp pakketopdrachten ingeschakeld, kunt u de pakketten zien die worden ontvangen en verzonden, en u kunt zien dat NTP op die pakketten reageert. Voor elk ontvangen NTP-pakket (zoals getoond door debug ip-pakket ) is er een corresponderende vermelding die gegenereerd is door debug ntp-pakketten .
Dit is de debug-uitvoer wanneer het NTP-proces aan ontvangen pakketten werkt:
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 (10.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 (10.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)
Dit is een voorbeeld waar NTP niet aan ontvangen pakketten werkt. Hoewel NTP-pakketten worden ontvangen (zoals getoond door debug IP-pakketten), werkt het NTP-proces niet op deze pakketten. Voor NTP-pakketten die worden verzonden, is een corresponderende debug-ntp-pakketuitvoer aanwezig, omdat het NTP-proces het pakket moet genereren. De kwestie is specifiek voor ontvangen NTP-pakketten die niet worden verwerkt.
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#
Verlies van synchronisatie
Er kan synchronisatie-verlies optreden als de dispersie- en/of vertragingswaarde voor een server erg hoog wordt. Hoge waarden geven aan dat de pakketten te lang duren om van de server/peer naar de client te gaan met verwijzing naar de hoofdpagina van de kloktijd. De lokale machine kan dus niet vertrouwen op de nauwkeurigheid van de tijd die in het pakje zit, omdat het niet weet hoe lang het duurde voordat het pakje hier kwam.
NTP is uiterst nauwkeurig over tijd en kan niet synchroniseren met een ander apparaat dat het niet kan vertrouwen of niet kan aanpassen zodat het kan worden vertrouwd.
Als er een verzadigde verbinding en buffering langs de weg voorkomen, worden de pakketten vertraagd aangezien zij aan de cliënt NTP komen. Dus de tijdstempel in een volgend NTP pakket kan af en toe veel variëren, en de lokale client kan niet echt aanpassen aan die variantie.
NTP biedt geen methode om de validatie van deze pakketten uit te schakelen, tenzij u Simple Network Time Protocol (SNTP) gebruikt. SNTP is niet veel een alternatief omdat het niet breed ondersteund wordt in software.
Als u verlies van synchronisatie ervaart, moet u de koppelingen controleren:
- Zijn ze verzadigd?
- Zijn er verschillende soorten druppels in uw Wide Area Network (WAN) links?
- Is er encryptie?
Controleer de bereikwaarde van de show ntp associaties detail opdracht. De hoogste waarde is 377. Als de waarde 0 of laag is, worden NTP-pakketten met tussenpozen ontvangen, en gaat de lokale client niet synchroon met de server.
Opdracht NTP-geldigheid zuiveren
De opdracht NTP-validiteit debug geeft aan of het NTP-pakket faalde bij de controle van de juistheid of de geldigheid en onthult de reden voor de fout. Vergelijk deze uitvoer met de sanitaire tests die in RFC1305 zijn gespecificeerd en die worden gebruikt om het NTP-pakket te testen dat van een server wordt ontvangen. Er worden acht tests gedefinieerd:
| Testen |
Masker |
Toelichting |
|---|---|---|
| 1 |
0x01 |
Dubbel ontvangen pakket. |
| 2 |
0x02 |
Bogus-pakket ontvangen. |
| 3 |
0x04 |
Protocol niet gesynchroniseerd. |
| 4 |
0x08 |
Grenscontrole peer vertraging/dispersie is mislukt. |
| 5 |
0x10 |
Verificatie door peers is mislukt. |
| 6 |
0x20 |
Peer klok niet-gesynchroniseerd (gebruikelijk voor niet-gesynchroniseerde server). |
| 7 |
0x40 |
Peer stratum niet gebonden. |
| 8 |
0x80 |
Grenscontrole van wortelvertraging/dispersie is mislukt. |
Dit is voorbeelduitvoer van van de debug ntp validiteitsopdracht:
PCY_PAS1#debug ntp validity
NTP peer validity debugging is on
009585: Mar 1 2012 09:14:32.670 HIVER: NTP: packet from 192.168.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 10.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.168.113.57failed 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 10.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 10.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.168.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 10.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.168.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
Opdracht NTP-pakketten zuiveren
U kunt de opdracht debug ntp-pakketten gebruiken om de tijd te zien die de peer/server u geeft in het ontvangen pakket. De lokale machine van de tijd vertelt ook de tijd het aan de peer/server in het overgebrachte pakket kent.
| Veld | rcv-pakket | Pakket verzenden |
|---|---|---|
| org | Tijdstempel van de maker, dat is de servertijd. | De tijdzegel van de schepper (cliënt) toen het pakket verzond. (De client genereert een pakket naar de server.) |
| overw | Tijdstempel op de client bij ontvangst van het pakket. | Huidige tijd client |
In deze voorbeelduitvoer zijn de tijdstempels in het ontvangen pakket van de server en het pakket dat naar een andere server is verzonden hetzelfde, wat aangeeft dat de client-NTP synchroon is.
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 (10.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)
Dit is een voorbeeld van uitvoer wanneer de klokken niet synchroon zijn. Let op het tijdsverschil tussen het exmit pakket en het rcv pakket. De peer dispersie kan bij de maximumwaarde van 16000 zijn, en het bereik voor de peer kan 0 tonen.
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 (10.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 en debug ntp gebeurtenissen Opdrachten
De opdracht debug ntp sync produceert output met één regel die aangeeft of de kloktijd gesynchroniseerd is of de sync is gewijzigd. De opdracht is over het algemeen ingeschakeld met debug ntp-gebeurtenissen.
De opdracht debug ntp events toont alle NTP-gebeurtenissen die plaatsvinden, wat u helpt bepalen of een wijziging in NTP een probleem heeft veroorzaakt zoals klokken die niet synchroon lopen. (Met andere woorden, als je gelukkig gesynchrone klokken plotseling gek worden, weet je om te zoeken naar een verandering of trigger!)
Dit is een voorbeeld van beide debugs. Aanvankelijk werden de cliëntklokken gesynchroniseerd. De opdracht debug ntp events laat zien dat er een wijziging in NTP-peer stratum heeft plaatsgevonden, en de klokken toen uit sync zijn geraakt.
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 (10.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)
NTP-klokperiode handmatig instellen
Op de website Cisco.com wordt gewaarschuwd:
"Het ntp klokperiode-bevel wordt automatisch geproduceerd om op de correctiefactor te wijzen die constant verandert wanneer het bevel van de exemplaar in werking stelt-configuratie opstarten-configuratie is ingegaan om de configuratie aan NVRAM op te slaan. Probeer niet om de ntp klok-periode opdracht handmatig te gebruiken. Zorg ervoor dat u deze opdrachtregel verwijdert wanneer u configuratiebestanden naar andere apparaten kopieert."
De waarde voor de kloktijd is afhankelijk van de hardware en verschilt dus voor elk apparaat.
Het ntp klokperiode-bevel verschijnt automatisch in de configuratie wanneer u NTP toelaat. De opdracht wordt gebruikt om de softwareklok aan te passen. De aanpassingswaarde compenseert het aanvinkinterval van 4 msec, zodat u met de kleine aanpassing 1 seconde aan het eind van het interval hebt.
Als het apparaat heeft berekend dat zijn systeemklok tijd verliest (misschien moet er een frequentiecompensatie van het basisniveau van de router zijn), voegt het automatisch deze waarde aan de systeemklok toe om zijn synchroniciteit te handhaven. Deze opdracht mag niet door de gebruiker worden gewijzigd.
De standaard NTP klokperiode voor een router is 17179869 en wordt hoofdzakelijk gebruikt om het NTP proces te starten.
De conversieformule is 17179869 * 2^(-32) = 0.00399999995715916156768798828125, of ongeveer 4 milliseconden.
Zo is bijvoorbeeld gebleken dat de systeemklok voor Cisco 2611 routers (een van Cisco 2600 Series routers) iets niet synchroon is en met deze opdracht kan worden gesynchroniseerd:
ntp clock-period 17208078
Dit is gelijk aan 17208078 * 2^(-32) = 0.0040065678767859935760498046875, of iets meer dan 4 milliseconden.
Cisco raadt u aan de router een week of zo in normale netwerkomstandigheden te laten draaien en vervolgens de opdracht WRP-mem te gebruiken om de waarde op te slaan. Dit geeft u een nauwkeurige figuur voor de volgende reboot en maakt NTP sneller te synchroniseren.
Gebruik het bevel ntp klok-periode wanneer u de configuratie voor gebruik op een ander apparaat opslaat omdat dit bevel de klokperiode terug naar het gebrek van dat bepaalde apparaat laat vallen. U kunt de werkelijke waarde opnieuw berekenen (maar u kunt de nauwkeurigheid van de systeemklok tijdens die herberekeningsperiode verminderen).
Vergeet niet dat deze waarde hardware-afhankelijk is, dus als u een configuratie kopieert en deze op verschillende apparaten gebruikt, kunt u problemen veroorzaken. Cisco is van plan NTP versie 3 te vervangen door versie 4 om dit probleem op te lossen.
Als u zich niet bewust bent van deze problemen, kunt u beslissen om handmatig te knutselen met deze waarde. Om te migreren van het ene apparaat naar het andere, kunt u beslissen om de oude configuratie te kopiëren en te plakken op het nieuwe apparaat. Helaas, omdat de ntp klokperiode-opdracht verschijnt in het in werking stellen-config en opstarten-config, NTP klokperiode wordt geplakt op het nieuwe apparaat. Wanneer dit gebeurt, gaat NTP op de nieuwe client altijd uit de sync met de server met een hoge peer dispersie waarde.
In plaats daarvan, ontruim de NTP klokperiode met ntp klokperiode bevel, dan sparen de configuratie. De router berekent uiteindelijk een kloktijd die geschikt is voor zichzelf.
De opdracht voor de ntp-klokperiode is niet meer beschikbaar in Cisco IOS®-softwareversie 15.0 of hoger; de parser wijst nu de opdracht met de fout af:
"%NTP: This configuration command is deprecated."
U mag de klokperiode niet handmatig configureren, en de klokperiode is niet toegestaan in het in werking stellen-configureren. Aangezien de parser het commando afwijst als het in de start-up configuratie was (in eerdere Cisco IOS versies zoals 12.4), wijst de parser het commando af wanneer het de start-up configuratie kopieert naar de in werking stellen-config op boot-up.
De nieuwe, vervangende opdracht is ntp clear drift.
Gerelateerde informatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
4.0 |
12-Nov-2024 |
Bijgewerkte titel, brandende vereisten en opmaak. |
3.0 |
15-Aug-2024 |
Hercertificering. |
2.0 |
15-Feb-2023 |
Bijgewerkt formaat en informatie. Gecorrigeerde CCW. Hercertificering. |
1.0 |
06-May-2013 |
Eerste vrijgave |
Bijgedragen door Cisco-engineers
- Krishna NagavoluCisco Software Engineering - technisch aanvoerder
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)