Problemen met het 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
In dit document wordt beschreven hoe u problemen met het Network Time Protocol (NTP) kunt oplossen metdebugopdrachten en de show ntp opdracht.
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
Voordat u naar de oorzaak van NTP-problemen kijkt, moet u het gebruik en de uitvoer van deze opdrachten begrijpen:
- NTP-associatie weergeven
- NTP-associatiedetails weergeven
- NTP-status weergeven
Opmerking: Gebruik het opzoekprogramma voor opdrachten om meer informatie te verkrijgen over de opdrachten die in deze sectie worden gebruikt. Alleen geregistreerde Cisco-gebruikers hebben toegang tot interne tools en informatie.
Opmerking: Het gereedschap Uitvoertolk ondersteunt bepaalde opdrachten voor weergeven. Alleen geregistreerde Cisco-gebruikers hebben toegang tot interne tools en informatie.
ntp-associatiecommando weergeven
Een NTP-associatie kan zijn:
- een peer-associatie (het ene systeem is bereid om te synchroniseren met het andere systeem, of om het andere systeem ermee te laten synchroniseren.)
- een serverkoppeling (Slechts één systeem synchroniseert met het andere systeem en niet andersom.)
Dit is een voorbeeld van uitvoer van de opdracht NTP-associatie weergeven:
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 | verklaring |
|---|---|
|
Tekens voor het adres hebben de volgende definities:
|
|
|
adres |
Dit is het IP-adres van de peer. In het voorbeeld toont het eerste item 127.127.7.1. Dit geeft aan dat het lokale systeem met zichzelf is gesynchroniseerd. Over het algemeen synchroniseert alleen een primaire NTP met zichzelf. |
|
ref-klok |
Dit is het adres van de referentieklok voor de peer. In het voorbeeld hebben de eerste zes peers / servers een privé-IP als referentieklok, dus hun primaire gegevens zijn waarschijnlijk routers, switches of servers binnen het lokale netwerk. Voor de laatste vier inzendingen is de referentieklok een openbare IP, dus hun voorverkiezingen zijn waarschijnlijk een openbare tijdbron. |
|
st |
NTP gebruikt het concept van een stratum om te beschrijven hoe ver weg (in NTP-hop) een machine is van een gezaghebbende tijdbron. Een stratum 1-tijdserver heeft bijvoorbeeld een radio of atoomklok die er direct op is aangesloten. Het stuurt zijn tijd naar een stratum 2 tijdserver via NTP, en zo verder tot stratum 16. Een machine die NTP uitvoert, kiest automatisch de machine met het laagste stratumnummer waarmee deze kan communiceren en gebruikt NTP als tijdbron. |
|
wanneer |
De tijd sinds het laatste NTP-pakket van een peer is ontvangen, wordt in seconden gerapporteerd. Deze waarde moet lager zijn dan het polling interval. |
|
opinieonderzoek |
Het stemmingsinterval wordt in seconden gerapporteerd. Het interval begint meestal met een minimum van 64-seconden poll-intervallen. De RFC specificeert dat er niet meer dan één NTP-transactie per minuut nodig is om twee machines te synchroniseren. Naarmate NTP stabiel wordt tussen een client en een server, kan het poll-interval in kleine stappen toenemen van 64 seconden tot 1024 seconden en stabiliseert het zich over het algemeen ergens tussenin. Maar deze waarde verandert dynamisch, op basis van 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 stapsgewijs verhoogd tot 1024 seconden om de netwerkoverhead te verminderen. Het is niet mogelijk om het NTP-poll-interval op een router aan te passen, omdat het interne interval wordt bepaald door heuristische algoritmen. |
|
bereik |
Peer bereikbaarheid is een bit string gerapporteerd als een octale waarde. Dit veld laat zien of de laatste acht pakketten zijn ontvangen door het NTP-proces op de Cisco IOS®-software. De pakketten moeten worden ontvangen, verwerkt en geaccepteerd 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 poll-interval is de tijd die NTP wacht voordat het concludeert dat een pakket verloren is gegaan. De poll tijd kan verschillend zijn voor verschillende peers, dus de tijd voordat bereik beslist dat een pakket verloren is gegaan, kan ook verschillend zijn voor verschillende peers. In het voorbeeld zijn er vier verschillende bereikwaarden:
Reach is een goede indicator van de vraag of NTP-pakketten worden verwijderd vanwege een slechte koppeling, CPU-problemen en andere intermitterende problemen. Unit Converter is een online unit converter voor deze en vele andere conversies. |
|
vertraging |
De vertraging van de retourvlucht naar peer wordt in milliseconden gerapporteerd. Om de klok nauwkeuriger in te stellen, wordt bij het instellen van de kloktijd rekening gehouden met deze vertraging. |
|
compenseren |
Offset is het kloktijdverschil tussen de peers of tussen de primaire en de client. Deze waarde is de correctie die wordt toegepast op een clientklok om deze te synchroniseren. Een positieve waarde geeft aan dat de serverklok hoger is. Een negatieve waarde geeft aan dat de clientklok hoger is. |
|
disp |
Dispersie, gerapporteerd in seconden, is het maximale kloktijdverschil dat ooit werd waargenomen tussen de lokale klok en de serverklok. In het voorbeeld is de dispersie 0,3 voor de server 10.50.36.42, dus het maximale tijdsverschil dat ooit lokaal is waargenomen tussen de lokale klok en de serverklok is 0,3 seconden. U kunt een hoge waarde verwachten wanneer de klokken in eerste instantie worden gesynchroniseerd. Maar als de verspreiding op andere momenten te hoog is, accepteert het NTP-proces op de client geen NTP-berichten van de server. De maximale dispersie is 16000; in het voorbeeld is dat de dispersie voor servers 10.50.44.69 en 10.50.44.133, dus de lokale client accepteert geen tijd van deze servers. Als het bereik nul is en de verspreiding erg hoog is, accepteert de client waarschijnlijk geen berichten van die server. Zie de tweede regel van het voorbeeld: address ref clock st when poll reach delay offset disp Hoewel de offset slechts -4,26 is, is de dispersie erg hoog (misschien vanwege een gebeurtenis in het verleden) en is het bereik nul, dus deze client accepteert geen tijd van deze server. |
ntp-associatiedetail tonen, opdracht
Dit is een voorbeeld van uitvoer van de opdracht show ntp association 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 al zijn gedefinieerd in het gedeelte Show up Association worden hier niet herhaald.
|
Begrip |
verklaring | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
geconfigureerd |
Deze NTP-klokbron is geconfigureerd als een server. Deze waarde kan ook dynamisch zijn, waarbij de peer/server dynamisch werd ontdekt. |
|||||||||||||||||||||||||||
|
our_primary |
De lokale client wordt gesynchroniseerd met deze peer. |
|||||||||||||||||||||||||||
|
geselecteerd |
De peer/server wordt geselecteerd voor mogelijke synchronisatie, wanneer our_primary mislukt of de client de synchronisatie verliest. |
|||||||||||||||||||||||||||
|
gezond |
Sanity-tests worden gebruikt om het NTP-pakket te testen dat van een server wordt ontvangen. Deze tests zijn gespecificeerd in RFC 1305, Network Time Protocol (versie 3) Specification, Implementation and Analysis. De tests zijn:
De pakketgegevens zijn geldig als de tests 1 tot en met 4 slagen. De gegevens worden vervolgens gebruikt om offset, vertraging en dispersie te berekenen. Pakketkoptekst 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 op gezond verstand zijn mislukt, dus de tijd vanaf de server wordt niet geaccepteerd. De server is niet gesynchroniseerd. |
|||||||||||||||||||||||||||
|
valide |
De peer/server tijd is geldig. De lokale client accepteert deze tijd als deze peer de primaire wordt. |
|||||||||||||||||||||||||||
|
ongeldig |
De peer/server-tijd is ongeldig en de tijd kan niet worden geaccepteerd. |
|||||||||||||||||||||||||||
|
ref-ID |
Aan elke peer/server wordt een referentie-ID (label) toegewezen. |
|||||||||||||||||||||||||||
|
tijdsduur |
Tijd is de laatste tijdstempel die van die peer/server is ontvangen. |
|||||||||||||||||||||||||||
|
Onze modus/Peer-modus |
Dit is de status van de lokale client/peer. |
|||||||||||||||||||||||||||
|
Onze poll INTVL/ Peer Poll INTVL |
Dit is het poll-interval van onze poll naar deze 'peer', of van de 'peer' naar de lokale machine. |
|||||||||||||||||||||||||||
|
root delay |
Root delay is de vertraging in milliseconden van de root van de NTP-setup. Stratum 1 klokken worden beschouwd als de wortel van een NTP setup / ontwerp. In het voorbeeld kunnen alle drie de servers de root zijn omdat ze zich op stratum 1 bevinden. |
|||||||||||||||||||||||||||
|
worteldispersie |
Worteldispersie is het maximale kloktijdverschil dat ooit is waargenomen tussen de lokale klok en de wortelklok. Zie de uitleg van disp onder show up associatie voor meer details. |
|||||||||||||||||||||||||||
|
Synchronisatiedist. |
Dit is een schatting van het maximale verschil tussen de tijd op de stratum 0-bron en de door de klant gemeten tijd. Het bestaat uit componenten voor retourtijd, systeemprecisie en klokdrift sinds de laatste werkelijke aflezing van de stratumbron. In een grote NTP-configuratie (NTP-servers op stratum 1 op het internet, met servers die de brontijd op verschillende strata gebruiken) met servers / clients op meerdere strata, moet de NTP-synchronisatietopologie worden georganiseerd om de hoogste nauwkeurigheid te produceren, maar mag nooit een tijdsynchronisatielus vormen. Een bijkomende factor is dat elke toename in stratum een potentieel onbetrouwbare tijdserver omvat, die extra meetfouten introduceert. Het selectiealgoritme dat in NTP wordt gebruikt, maakt gebruik van een variant van het Bellman-Ford gedistribueerde routeringsalgoritme om het minimumgewicht te berekenen dat bomen omspant die op de primaire servers zijn geworteld. De afstandsmetriek die door het algoritme wordt gebruikt, bestaat uit het stratum plus de synchronisatieafstand, die zelf bestaat uit de dispersie plus de helft van de absolute vertraging. Het synchronisatiepad neemt dus altijd het minimale aantal servers naar de root; banden worden opgelost op basis van maximale fouten. |
|||||||||||||||||||||||||||
|
vertraging |
Dit is de retourvertraging naar peer. |
|||||||||||||||||||||||||||
|
precisie |
Dit is de precisie van de peerklok in Hz. |
|||||||||||||||||||||||||||
|
versie |
Dit is het NTP-versienummer dat door de peer wordt gebruikt. |
|||||||||||||||||||||||||||
|
org-tijd |
Dit is de tijdstempel van de NTP-pakketinitiator; met andere woorden, het is de peer-tijdstempel toen het het NTP-pakket maakte, maar voordat het het pakket naar de lokale client stuurde. |
|||||||||||||||||||||||||||
|
RCV-tijd |
Dit is de tijdstempel waarop de lokale client het bericht heeft ontvangen. Het verschil tussen de org-tijd en de rcv-tijd is de offset voor deze peer. In het voorbeeld heeft primair 10.4.2.254 deze tijden: org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012) Het verschil is de offset van 268,3044 msec. |
|||||||||||||||||||||||||||
|
XMT-tijd |
Dit is de tijdstempel voor het verzenden van het NTP-pakket dat de lokale client naar deze peer/server verzendt. |
|||||||||||||||||||||||||||
|
filtervertraging |
Dit is de retourvertraging in milliseconden van elk monster. Een sample is het laatste ontvangen NTP pakket. 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 samples komen overeen met de waarde van het reach-veld, dat aangeeft of de lokale client de laatste acht NTP-pakketten heeft ontvangen. |
ntp-status weergeven, opdracht
Dit is een voorbeeld van uitvoer van de opdracht NTP-status tonen:
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 al zijn gedefinieerd in het gedeelte Show up Association of het gedeelte Show NTP Association Details worden niet herhaald.
| Begrip | verklaring |
|---|---|
|
precisie |
De precisie wordt automatisch bepaald en wordt gemeten als een vermogen van twee. In het voorbeeld betekent 2**18 2^(-18), of 3,8 microseconden. Verlies van synchronisatie tussen NTP-peers of tussen een primaire en client kan te wijten zijn aan een verscheidenheid aan oorzaken. NTP vermijdt synchronisatie met een machine waarvan de tijd op deze manieren dubbelzinnig kan zijn:
|
Problemen met NTP oplossen met fouten
De meest voorkomende oorzaken van NTP problemen zijn:
- NTP-pakketten worden niet ontvangen.
- NTP-pakketten worden ontvangen, maar worden niet verwerkt door het NTP-proces op Cisco IOS®.
- NTP-pakketten worden verwerkt, maar foutieve factoren of pakketgegevens veroorzaken het verlies van synchronisatie.
- De NTP-klokperiode wordt handmatig ingesteld.
Belangrijke foutopsporingsopdrachten die helpen bij het isoleren van de oorzaak van deze problemen zijn:
- IP-pakketten voor foutopsporing <acl>
- NTP-pakketten debuggen
- Foutopsporings-NTP-geldigheid
- Foutopsporings-NTP-synchronisatie
- NTP-gebeurtenissen debuggen
De volgende secties illustreren het gebruik van debugs om deze veelvoorkomende problemen op te lossen.
Opmerking: Gebruik het opzoekprogramma voor opdrachten om meer informatie te verkrijgen over de opdrachten die in deze sectie worden gebruikt. Alleen geregistreerde Cisco-gebruikers hebben toegang tot interne tools en informatie.
Opmerking: raadpleeg Belangrijke informatie over debug-opdrachten voordat u debug-opdrachten gebruikt.
NTP-pakketten niet ontvangen
Gebruik de opdracht IP-pakket debuggen om te controleren of NTP-pakketten worden ontvangen en verzonden. Omdat debug-uitvoer praatgraag kan zijn, kunt u debug-uitvoer beperken met het gebruik van Access Control Lists (ACL's). NTP maakt gebruik van User Datagram Protocol (UDP) poort 123.
- ACL 101 maken:
access-list 101 permit udp any any eq 123
NTP-pakketten hebben meestal een bron- en bestemmingspoort van 123, dus 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 het debug ip packet commando te beperken:
debug ip packet 101
- Als het probleem met bepaalde peers is, beperk dan de 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 zijn ontvangen, moet u:
- Controleer of NTP correct is geconfigureerd.
- Controleer of een ACL NTP-pakketten blokkeert.
- Controleren op routeringsproblemen naar de bron- of bestemmings-IP.
NTP-pakketten niet verwerkt
Met zowel debug ip pakket en debug ntp pakketten opdrachten ingeschakeld, kunt u de pakketten die worden ontvangen en verzonden te zien, en u kunt zien dat NTP werkt op die pakketten. Voor elk ontvangen NTP-pakket (zoals getoond door debug ip-pakket ), is er een overeenkomstige vermelding gegenereerd door debug ntp-pakketten.
Dit is de foutopsporingsuitvoer wanneer het NTP-proces werkt op ontvangen pakketten:
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 waarbij NTP niet werkt op ontvangen pakketten. Hoewel NTP-pakketten worden ontvangen (zoals blijkt uit debug ip-pakketten), werkt het NTP-proces er niet op in. Voor NTP-pakketten die worden verzonden, is een overeenkomstige debug ntp-pakketuitvoer aanwezig, omdat het NTP-proces het pakket moet genereren. Het probleem 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
Verlies van synchronisatie kan optreden als de dispersie- en/of vertragingswaarde voor een server erg hoog wordt. Hoge waarden geven aan dat de pakketten te lang duren om vanaf de server / peer naar de client te gaan met betrekking tot de hoofdmap van de klok. Dus de lokale machine kan de nauwkeurigheid van de tijd in het pakket niet vertrouwen, omdat het niet weet hoe lang het duurde voordat het pakket hier kwam.
NTP is zorgvuldig over tijd en kan niet synchroniseren met een ander apparaat dat het niet kan vertrouwen of niet op een manier kan aanpassen zodat het kan worden vertrouwd.
Als er een verzadigde link is en er onderweg buffering plaatsvindt, worden de pakketten vertraagd als ze naar de NTP-client komen. Dus de tijdstempel in een volgend NTP-pakket kan af en toe veel variëren en de lokale client kan zich 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 echt een alternatief, omdat het niet op grote schaal wordt ondersteund in software.
Als u synchronisatieverlies ervaart, moet u de koppelingen controleren:
- Zijn ze verzadigd?
- Zijn er verschillende soorten van druppels in uw Wide Area Network (WAN) links?
- Doet encryptie zich voor?
Controleer de bereikwaarde met de opdracht NTP-associaties weergeven. De hoogste waarde is 377. Als de waarde 0 of laag is, worden NTP-pakketten met tussenpozen ontvangen en loopt de lokale client niet synchroon met de server.
foutopsporings-ntp-validiteitsopdracht
De foutopsporings-opdracht ntp-validiteit geeft aan of het NTP-pakket geen gezonde of geldige controles heeft uitgevoerd en onthult de reden voor de fout. Vergelijk deze uitvoer met de in RFC1305 gespecificeerde gezondheidstests die worden gebruikt om het NTP-pakket te testen dat van een server is ontvangen. Er zijn acht tests gedefinieerd:
|
testen |
Masker |
verklaring |
|---|---|---|
|
1 |
0x01 |
Dupliceer pakket ontvangen. |
|
2 |
0x02 |
Schijnpakket ontvangen. |
|
3 |
0x04 |
Protocol niet-gesynchroniseerd. |
|
4 |
0x08 |
Peer delay/dispersion faalde grenscontrole. |
|
5 |
0x10 |
Peer-verificatie mislukt. |
|
6 |
0x20 |
Peer-klok niet-gesynchroniseerd (gebruikelijk voor niet-gesynchroniseerde server). |
|
7 |
0x40 |
Peer stratum out of bound. |
|
8 |
0x80 |
Wortelvertraging/dispersie mislukte grenscontrole. |
Dit is een voorbeeld van uitvoer van de opdracht foutopsporingsvaliditeit ntp:
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
foutopsporings-ntp-pakketten, opdracht
U kunt de opdracht debug ntp packets gebruiken om de tijd te zien die de peer / server u in het ontvangen pakket geeft. De lokale tijdmachine vertelt ook de tijd die het kent aan de peer / server in het verzonden pakket.
| Veld | rcv-pakket | XMIT-pakket |
|---|---|---|
| org | Originator tijdstempel, dat is de server tijd. | Originator (client) tijdstempel wanneer het pakket verzonden. (Client verzendt een pakket naar de server.) |
| overw | Tijdstempel op de client wanneer deze het pakket heeft ontvangen. | Huidige tijd van de klant. |
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 is gesynchroniseerd.
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 gesynchroniseerd zijn. Let op het tijdsverschil tussen het xmit-pakket en het rcv-pakket. De peer-dispersie kan de maximale waarde van 16000 hebben 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)
foutopsporing ntp synchroniseren en foutopsporing ntp gebeurtenissen Opdrachten
De opdracht debug ntp sync produceert één regel uitgangen die laten zien of de klok is gesynchroniseerd of de synchronisatie is gewijzigd. De opdracht is over het algemeen ingeschakeld met foutopsporings-ntp-gebeurtenissen.
De opdracht NTP-gebeurtenissen debuggen toont alle NTP-gebeurtenissen die plaatsvinden, waardoor u kunt bepalen of een wijziging in de NTP een probleem heeft veroorzaakt, zoals klokken die niet synchroon lopen. (Met andere woorden, als je gelukkig gesynchroniseerde klokken plotseling gek worden, weet je dat je moet zoeken naar een verandering of trigger!)
Dit is een voorbeeld van beide debugs. Aanvankelijk werden de klokken van de client gesynchroniseerd. De opdracht foutopsporing ntp-gebeurtenissen laat zien dat er een verandering in de NTP-peer-stratum heeft plaatsgevonden en dat de klokken vervolgens niet meer gesynchroniseerd zijn.
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 ingesteld
De website Cisco.com waarschuwt dat:
"De opdracht ntp-klokperiode wordt automatisch gegenereerd om de correctiefactor weer te geven die voortdurend verandert wanneer de opdracht copy running-configuration startup-configuration wordt ingevoerd om de configuratie op te slaan in NVRAM. Probeer niet handmatig de opdracht ntp-klokperiode te gebruiken. Zorg ervoor dat u deze opdrachtregel verwijdert wanneer u configuratiebestanden naar andere apparaten kopieert."
De waarde van de klokperiode is afhankelijk van de hardware, dus deze verschilt voor elk apparaat.
De opdracht ntp-klokperiode wordt automatisch weergegeven in de configuratie wanneer u ntp inschakelt. De opdracht wordt gebruikt om de softwareklok aan te passen. De instelwaarde compenseert het 4 msec tekeninterval, zodat u met de kleine aanpassing 1 seconde aan het einde van het interval hebt.
Als het apparaat heeft berekend dat de systeemklok tijd verliest (misschien moet er een frequentiecompensatie zijn vanaf het basisniveau van de router), voegt het deze waarde automatisch toe aan de systeemklok om de synchroniciteit te behouden. Deze opdracht mag niet door de gebruiker worden gewijzigd.
De standaard NTP-klokperiode voor een router is 17179869 en wordt in wezen gebruikt om het NTP-proces te starten.
De omrekeningsformule is 17179869 * 2^(-32) = 0,0039999995715916156768798828125, of ongeveer 4 milliseconden.
De systeemklok voor de Cisco 2611-routers (een van de Cisco 2600 Series Routers) bleek bijvoorbeeld enigszins niet synchroon te zijn en kon opnieuw worden gesynchroniseerd met deze opdracht:
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 Wr mem te gebruiken om de waarde op te slaan. Dit geeft u een nauwkeurig cijfer voor de volgende herstart en maakt NTP sneller te synchroniseren.
Gebruik de opdracht geen ntp-klokperiode wanneer u de configuratie opslaat voor gebruik op een ander apparaat, omdat deze opdracht de klokperiode terugbrengt naar de standaardwaarde van dat specifieke apparaat. U kunt de werkelijke waarde opnieuw berekenen (maar u kunt de nauwkeurigheid van de systeemklok tijdens die herberekeningsperiode verminderen).
Vergeet niet dat deze waarde afhankelijk is van de hardware, dus als u een configuratie kopieert en deze op verschillende apparaten gebruikt, kunt u problemen veroorzaken. Cisco is van plan om 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 besluiten om handmatig te sleutelen aan deze waarde. Om van het ene apparaat naar het andere te migreren, kunt u besluiten om de oude configuratie te kopiëren en op het nieuwe apparaat te plakken. Helaas, omdat de ntp-klokperiode opdracht wordt weergegeven in de running-config en startup-config, NTP-klokperiode wordt geplakt op het nieuwe apparaat. Wanneer dit gebeurt, loopt NTP op de nieuwe client altijd synchroon met de server met een hoge peer-dispersiewaarde.
Maak in plaats daarvan de NTP-klokperiode leeg met de opdracht geen ntp-klokperiode en sla vervolgens de configuratie op. De router berekent uiteindelijk een klokperiode die geschikt is voor zichzelf.
De opdracht ntp-klokperiode is niet langer beschikbaar in Cisco IOS®-softwareversie 15.0 of hoger; de parser wijst de opdracht nu af met de fout:
"%NTP: This configuration command is deprecated."
U mag de klokperiode niet handmatig configureren en de klokperiode is niet toegestaan in de actieve configuratie. Aangezien de parser de opdracht afwijst als deze zich in de opstartconfiguratie bevond (in eerdere Cisco IOS-versies zoals 12.4), wijst de parser de opdracht af wanneer deze de opstartconfiguratie kopieert naar de actieve configuratie bij het opstarten.
De nieuwe, vervangende opdracht is ntp clear drift.
Gerelateerde informatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
5.0 |
04-Nov-2025
|
hercertificering |
4.0 |
12-Nov-2024
|
Bijgewerkte titel, merkvereisten en opmaak. |
3.0 |
15-Aug-2024
|
Hercertificering. |
2.0 |
15-Feb-2023
|
Bijgewerkt formaat en informatie. Gecorrigeerd CCW. Hercertificering. |
1.0 |
06-May-2013
|
Eerste vrijgave |
Bijgedragen door Cisco-engineers
- Krishna NagavoluTechnisch leider van Cisco Software Engineering
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)