Network Time Protocol (NTP) Problemen oplossen en Debugging Guide
Inhoud
Inleiding
Dit document beschrijft het gebruik van wachtwoorden om NTP-problemen (Network Time Protocol) bij te stellen, evenals de uitvoer van belangrijke NTP-opdrachten.
NTP-show Opdrachten
Voordat u de oorzaak van NTP-problemen bekijkt, dient u het gebruik van en de uitvoer van deze opdrachten te begrijpen:
- ntp-associatie tonen
- details van ntp-associatie tonen
- ntp status tonen
ntp-associatie tonen
Een NTP-associatie kan een peer association zijn (het ene systeem is bereid te synchroniseren met het andere systeem of het andere systeem toe te staan er aan te synchroniseren) of een server association (slechts één systeem synchroniseert met het andere systeem en niet andersom).
Dit is een voorbeeld van output van het tonen ntp associatie bevel:
CLA_PASA#sh ntp association
address ref clock st when poll reach delay offset disp
~127.127.7.1 127.127.7.1 9 50 64 377 0.0 0.00 0.0
~10.50.44.69 10.50.36.106 5 21231 1024 0 3.8 -4.26 16000.
+~10.50.44.101 10.50.38.114 5 57 64 1 3.6 -4.30 15875.
+~10.50.44.37 10.50.36.50 5 1 256 377 0.8 1.24 0.2
~10.50.44.133 10.50.38.170 5 12142 1024 0 3.2 1.24 16000.
+~10.50.44.165 10.50.38.178 5 35 256 357 2.5 -4.09 0.2
+~10.50.38.42 86.79.127.250 4 7 256 377 0.8 -0.29 0.2
*~10.50.36.42 86.79.127.250 4 188 256 377 0.7 -0.17 0.3
+~10.50.38.50 86.79.127.250 4 42 256 377 0.9 1.02 0.4
+~10.50.36.50 86.79.127.250 4 20 256 377 0.7 0.87 0.5
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
| Term | verklaring |
|---|---|
Tekens vóór het adres hebben deze definities:
|
|
richten |
Dit is het IP-adres van de peer. In het voorbeeld toont de eerste ingang 127.127.7.1. Dit geeft aan dat de lokale machine met zichzelf heeft gesynchroniseerd. Over het algemeen, slechts een NTP master syncs 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, zodat hun meesters waarschijnlijk routers, switches of servers binnen het lokale netwerk zijn. Voor de laatste vier ingangen is de referentieklok een openbare IP, zodat hun meesters waarschijnlijk een openbare tijdbron zijn. |
est |
NTP gebruikt het concept van een stratum om te beschrijven hoe ver weg (in NTP-hoop) een machine van een gezaghebbende tijdbron is. Een stratum 1-tijdserver heeft bijvoorbeeld een radio- of atomaire klok die er direct aan gekoppeld is. Het stuurt zijn tijd naar een stratum 2-time server via NTP en zo verder naar stratum 16. Een machine die NTP runt kiest automatisch de machine met het laagste stratumnummer waarmee het NTP kan communiceren en NTP als tijdbron gebruikt. |
wanneer |
De tijd sinds het laatste NTP-pakket van een peer werd ontvangen wordt in seconden gemeld. Deze waarde moet lager zijn dan het steminterval. |
opiniepeiling |
Het steminterval wordt in seconden gerapporteerd. Het interval begint gewoonlijk met een minimum van 64-seconden poll intervallen. De RFC specificeert dat niet meer dan één NTP-transactie per minuut nodig is om twee machines te synchroniseren. Wanneer NTP stabiel wordt tussen een client en een server, kan het poll interval in kleine stappen toenemen van 64 seconden tot 1024 seconden en over het algemeen stabiel ergens tussen. Maar deze waarde verandert dynamisch, op basis van de netwerkomstandigheden tussen de client en de server en het verlies van NTP-pakketten. Als een server enige tijd onbereikbaar is, wordt het poll interval verhoogd in stappen tot 1024 seconden om netwerk overhead te verminderen. Het is niet mogelijk het NTP-poll-interval op een router aan te passen, omdat het interne interval wordt bepaald door heuristische algoritmen. |
bereiken |
Peer bereikbaarheid is een beetje string die gerapporteerd wordt als een octale waarde. Dit veld toont aan of de laatste acht pakketten door het NTP-proces zijn ontvangen op de Cisco IOS®-software. De pakketten moeten worden ontvangen, verwerkt, en als geldig door het NTP-proces geaccepteerd en niet alleen door de router of switch die de NTP IP-pakketten ontvangt. Reach gebruikt de poll interval voor een tijdje uit om te beslissen of een pakje al dan niet werd ontvangen. Het poll interval is de tijd dat NTP wacht voordat het concludeert dat een pakje verloren is. De verkiezingstijd kan voor verschillende gelijken verschillend zijn, zodat de tijd vóór reach besluit dat een pakje was verloren kan ook voor verschillende peers verschillen. In het voorbeeld zijn er vier verschillende reach-waarden:
Reach is een goede indicator van de vraag of de pakketten NTP wegens een slechte verbinding, cpu en andere intermitterende problemen worden gedropt. Converteren van octaal < - > binair getal is een online unit converter voor deze en vele andere conversies. |
vertraging |
De vertraging van de retourvlucht naar peer wordt in milliseconden gemeld. 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 master en de client. Deze waarde is de correctie die op een clientklok wordt toegepast om deze te synchroniseren. Een positieve waarde geeft aan dat de serverkloktijd hoger is. Een negatieve waarde geeft aan dat de clientkloktijd hoger is. |
ontslaan |
Dispersie, gemeld in seconden, is het maximale kloktijd verschil 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 tijdsverschil 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 aanvankelijk synchroon. Maar als de dispersie te hoog is op andere tijden, accepteert het NTP proces op de client geen NTP-berichten van de server. maximale dispersie bedraagt 16000; in het voorbeeld is dat de spreiding voor servers 10.50.44.69 en 10.50.44.133 , zodat de lokale klant 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 Hoewel de offset slechts -4.26 is, is de dispersie erg hoog (mogelijk door een gebeurtenis uit het verleden) en het bereik is nul, dus accepteert deze client geen tijd vanaf deze server. |
details van ntp-associatie tonen
Dit is een voorbeeld van uitvoer van de show ntp associatie detail opdracht:
Router#sho ntp assoc detail
10.4.2.254 configured, our_master, sane, valid, stratum 1
ref ID .GPS., time D36968AA.CC528FE7 (02:10:50.798 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.44, reach 377, sync dist 207.565
delay 2.99 msec, offset 268.3044 msec, dispersion 205.54
precision 2**19, version 3
org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012)
rcv time D36968B7.A2F44E2C (02:11:03.636 UTC Fri May 25 2012)
xmt time D36968B7.A21D3780 (02:11:03.633 UTC Fri May 25 2012)
filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72
filtoffset = 268.30 172.15 -452.49 -253.59 -462.03 -81.98 -58.04 22.38
filterror = 0.02 0.99 1.95 1.97 2.00 2.01 2.03 2.04
10.3.2.254 configured, selected, sane, valid, stratum 1
ref ID .GPS., time D36968BB.B16C4A21 (02:11:07.693 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 3.34, reach 377, sync dist 192.169
delay 0.84 msec, offset 280.3251 msec, dispersion 188.42
precision 2**19, version 3
org time D36968BD.E69085E4 (02:11:09.900 UTC Fri May 25 2012)
rcv time D36968BD.9EE9048B (02:11:09.620 UTC Fri May 25 2012)
xmt time D36968BD.9EA943EF (02:11:09.619 UTC Fri May 25 2012)
filtdelay = 0.84 0.75 663.68 0.67 0.72 968.05 714.07 1.14
filtoffset = 280.33 178.13 -286.52 42.88 41.41 -444.37 -320.25 35.15
filterror = 0.02 0.99 1.97 1.98 1.98 2.00 2.03 2.03
10.1.2.254 configured, insane, invalid, stratum 1
ref ID .GPS., time D3696D3D.BBB4FF24 (02:30:21.733 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 4.15, reach 1, sync dist 15879.654
delay 0.98 msec, offset 11.9876 msec, dispersion 15875.02
precision 2**19, version 3
org time D3696D3D.E4C253FE (02:30:21.893 UTC Fri May 25 2012)
rcv time D3696D3D.E1D0C1B9 (02:30:21.882 UTC Fri May 25 2012)
xmt time D3696D3D.E18A748D (02:30:21.881 UTC Fri May 25 2012)
filtdelay = 0.98 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 11.99 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 0.02 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
De termen die al zijn gedefinieerd in de tonen ntp - associatie - sectie worden niet herhaald.
Term |
verklaring | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
ingesteld |
Deze NTP-klokbron is ingesteld als een server. Deze waarde kan ook dynamisch zijn, waar de peer/server dynamisch werd ontdekt. |
|||||||||||||||||||||||||||
onze_master |
De lokale client is gesynchroniseerd met deze peer. |
|||||||||||||||||||||||||||
geselecteerd |
De peer/server is geselecteerd voor mogelijke synchronisatie, wanneer 'our_master' faalt of de client sync verliest. |
|||||||||||||||||||||||||||
redelijk |
Sanity tests 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 de testen 1 tot en met 4 zijn doorlopen. De gegevens worden vervolgens gebruikt om offset, vertraging en dispersie te berekenen. Packet header is geldig als de testen 5 tot 8 zijn geslaagd. Alleen pakketten met een geldige header kunnen worden gebruikt om te bepalen of een peer kan worden geselecteerd voor synchronisatie. |
|||||||||||||||||||||||||||
krankzinnig |
De controle van de hygiëne is mislukt, dus de tijd vanaf de server is niet geaccepteerd. De server is onsynchroon. |
|||||||||||||||||||||||||||
geldig |
De peer/server tijd is geldig. De lokale cliënt accepteert deze keer als deze peer de meester wordt. |
|||||||||||||||||||||||||||
ongeldig |
De peer/server tijd is ongeldig en de tijd wordt niet geaccepteerd. |
|||||||||||||||||||||||||||
ref-id |
Aan elke peer/server wordt een referentie-ID (label) toegewezen. |
|||||||||||||||||||||||||||
tijd |
Tijd is de laatste keer stempel die van die peer/server wordt ontvangen. |
|||||||||||||||||||||||||||
onze modus/ peer modus |
Dit is de status van de lokale client/peer. |
|||||||||||||||||||||||||||
ons opiniepeiling info |
Dit is het poll interval van onze poll naar deze peer of van de peer naar de lokale machine. |
|||||||||||||||||||||||||||
wortelvertraging |
Uitgestelde start is de vertraging in milliseconden aan de wortel van de NTP-instelling. Stratum 1 klokken worden beschouwd als de wortel van een NTP opzet/ontwerp. In het voorbeeld kunnen alle drie servers de wortel zijn omdat ze op stratum 1 staan. |
|||||||||||||||||||||||||||
worteldispersie |
Root-dispersie is het maximale kloktijd-verschil dat ooit is waargenomen tussen de lokale kloktijd en de basiskloktijd. Raadpleeg de uitleg van 'disp' in het NTP-associatiesecgedeelte voor meer informatie. |
|||||||||||||||||||||||||||
synchronisatiedop. |
Dit is een schatting van het maximale verschil tussen de tijd op stratum 0 en de door de cliënt gemeten tijd; het bestaat uit onderdelen voor de rondreis , de systeemprecisie en de klokverschuiving sinds de laatste echte lezing van de stratumbron . In een grote NTP-instelling (NTP-servers op stratum 1 in het internet, met servers die brontijd op verschillende strata hebben) met servers/klanten op meerdere lagen, dient NTP-synchronisatietopologie te worden georganiseerd om de hoogste nauwkeurigheid te bereiken, maar mag nooit worden toegestaan een tijdsync-lus te vormen. Een extra factor is dat elke toename in stratum een potentieel onbetrouwbare tijdserver omvat, wat extra meetfouten introduceert. Het selectiealgoritme dat in NTP wordt gebruikt, gebruikt een variant van het gedistribueerde routingalgoritme van Bellman-Ford om het minimum-gewicht omspannende bomen te berekenen die op de primaire servers zijn geworteld. De afstand die door het algoritme wordt gebruikt bestaat uit stratum plus de synchronisatieafstand, die zelf uit de dispersie plus de helft van de absolute vertraging bestaat. Synchronisatie-pad neemt dus altijd het minimale aantal servers naar de wortel; de partijen worden opgelost op basis van een maximale fout . |
|||||||||||||||||||||||||||
vertraging |
Dit is de rondreis vertraging. |
|||||||||||||||||||||||||||
nauwkeurigheid |
Dit is de precisie van de peer klok in Hz. |
|||||||||||||||||||||||||||
versie |
Dit is het NTP versienummer dat door de peer wordt gebruikt. |
|||||||||||||||||||||||||||
org tijd |
Dit is het tijdstempel van de NTP-pakketoriginator; met andere woorden: het is de tijdstempel van deze peer wanneer hij het NTP-pakket creëerde, maar voordat het pakje naar de lokale client werd verzonden. |
|||||||||||||||||||||||||||
rcv-tijd |
Dit is de tijdstempel wanneer de lokale klant het bericht heeft ontvangen. Het verschil tussen org tijd en rcv tijd is de offset voor deze peer. In het voorbeeld heeft master 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. |
|||||||||||||||||||||||||||
xt-tijd |
Dit is de verzendtijdstempel voor het NTP-pakket dat de lokale client naar deze peer/server stuurt. |
|||||||||||||||||||||||||||
uitstel |
Dit is de rondreisvertraging in milliseconden van elk monster. Een voorbeeld is het laatste ontvangen NTP-pakket. In het voorbeeld heeft master 10.4.2.254 deze waarden: filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72 Deze acht monsters komen overeen met de waarde van het reach veld, dat toont of de lokale client de laatste acht NTP-pakketten heeft ontvangen. |
ntp status tonen
Dit is een voorbeeld van uitvoer uit de opdracht TTP-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
De termen die reeds zijn gedefinieerd in het gedeelte show ntp association of in het gedeelte show ntp association details, worden niet herhaald.
| Term | verklaring |
|---|---|
nauwkeurigheid |
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 synchronisatieverlies tussen NTP-peers of tussen een master en client kan het gevolg zijn van een verscheidenheid aan oorzaken. NTP vermijdt synchronisatie met een machine waarvan de tijd op deze manieren dubbelzinnig zou kunnen zijn:
|
NTP-probleemoplossing met debugs
Enkele van de meest voorkomende oorzaken van NTP-emissies zijn:
- NTP-pakketten worden niet ontvangen.
- NTP-pakketten worden ontvangen, maar worden niet verwerkt door het NTP-proces op de IOS.
- NTP-pakketten worden verwerkt, maar onjuiste factoren of pakketgegevens veroorzaken het verlies van synchronisatie.
- NTP-kloktijd wordt handmatig ingesteld.
Belangrijke debug-opdrachten die u helpen de oorzaak van deze problemen te isoleren, zijn:
- ip-pakketten reinigen <acl>
- debug van ntp-pakketten
- debug ntp geldigheid
- debug ntp sync
- ntp-gebeurtenissen debug
In de volgende paragrafen wordt het gebruik van deposito's geïllustreerd om deze gemeenschappelijke problemen op te lossen.
NTP-pakketten niet ontvangen
Gebruik de opdracht ip-pakketten debug om te controleren of NTP-pakketten worden ontvangen en verzonden. Aangezien debug-uitvoer handig kan zijn, kunt u debug-uitvoer beperken met het gebruik van toegangscontrolelijsten (ACL’s). NTP gebruikt 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 doelpoort 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 uitvoer van het debug IP-pakketopdracht te beperken:
debug ip packet 101
- Als het probleem met bepaalde peers is, vergroot ACL 101 naar die peers. Als de peer 172.16.1.1 is, verander 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
Nadat u hebt bevestigd dat NTP-pakketten niet worden ontvangen, dient u:
- Controleer of NTP correct is ingesteld.
- Controleer of een ACL-pakketten blokkeert NTP-pakketten.
- Controleer op het routeren van problemen naar de bron of het doel-IP.
NTP-pakketten niet verwerkt
Met de opdrachten debug ip-pakketten en debug ntp-pakketten die zijn ingeschakeld, kunt u de pakketten zien die worden ontvangen en verzonden en u kunt zien dat NTP op deze pakketten handelt. Voor elk ontvangen NTP-pakket (zoals wordt getoond door IP-pakket te debug) is er een corresponderende ingang die door ntp-pakketten gegenereerd is.
Dit is de debug uitvoer wanneer het NTP-proces op 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 (71.80.83.0)
.Apr 20 00:16:34.143 UTC: ref D33B2952.4CC11CCF (00:16:18.299 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: rec D33B2962.49D3724D (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.49D997D0 (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: inp D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), routed
via FIB
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending
full packet
.Apr 20 00:16:36.283 UTC: NTP: xmit packet to 10.8.2.254:
.Apr 20 00:16:36.283 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 002F (0.717), rtdsp 11058F (17021.713), refid 0A0102FE
(10.1.2.254)
.Apr 20 00:16:36.283 UTC: ref D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: s=10.8.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:36.283 UTC: NTP: rcv packet from 10.8.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:36.283 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 0000 (0.000), rtdsp 0017 (0.351), refid 47505300 (71.80.83.0)
.Apr 20 00:16:36.283 UTC: ref D33B295B.8AF7FE33 (00:16:27.542 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: rec D33B2964.4A6AD269 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.4A7C00D0 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: inp D33B2964.498A755D (00:16:36.287 UTC Fri Apr 20 2012)
Dit is een voorbeeld waar NTP niet aan ontvangen pakketten werkt. Hoewel NTP-pakketten worden ontvangen (zoals wordt getoond door IP-pakketten te debug), reageert het NTP-proces niet op deze pakketten. Voor NTP-pakketten die worden verzonden, is er een corresponderende 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 synchronisering
Het synchronisatieverlies kan voorkomen als de dispersie en/of vertragingswaarde voor een server zeer hoog gaat. Hoge waarden wijzen erop dat de pakketten te lang duren om aan de client van de server/peer te geraken met betrekking tot de wortel van de klok. De lokale machine kan dus niet de nauwkeurigheid van de tijd vertrouwen die in het pakje aanwezig is, omdat het niet weet hoe lang het heeft geduurd voordat de pakje hier kwam.
NTP is nauwkeurig over tijd en zal niet synchroniseren met een ander apparaat dat het niet kan vertrouwen of kan zich niet op een manier aanpassen zodat het kan worden vertrouwd.
Als er een verzadigde link is en het bufferen zich langs de weg voordoet, worden de pakketten vertraagd als zij naar de NTP client komen. Dus, de timestamp in een volgend NTP pakket kan af en toe veel variëren en de lokale client kan niet echt aanpassen voor die variantie.
NTP biedt geen methode aan om de validatie van deze pakketten uit te schakelen tenzij u SNTP (Eenvoudig Protocol van de Tijd van het Netwerk) gebruikt. SNTP kan niet veel van een alternatief zijn omdat het niet breed ondersteund wordt in software.
Als u het synchronisatieverlies ervaren, moet u de links controleren:
- Zijn ze verzadigd?
- Zijn er soorten druppels in uw WAN-links (Wide Area Network)
- Is codering nodig?
Controleer de reach waarde van de show ntp associaties opdracht. De hoogste waarde is 377. Als de waarde 0 of laag is, worden NTP-pakketten met tussenpozen ontvangen, en de lokale client gaat uit sync met de server.
debug ntp geldigheid
De opdracht debug ntp validatie geeft aan of het NTP-pakket geen hygiëne- of validatiecontroles heeft uitgevoerd en onthult de reden voor de mislukking. Vergelijk deze uitvoer met de gezondheidstests 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:
| Test | Masker | verklaring |
|---|---|---|
| 1 | 0x01 | Dubbelpakket ontvangen |
| 2 | 0x02 | Boguspakketontvangst ontvangen |
| 3 | 0x04 | Protocol niet gesynchroniseerd |
| 4 | 0x08 | Peregelvertraging/dispersie mislukt grenscontrole |
| 5 | 0x10 | Peer-verificatie mislukt |
| 6 | 0x20 | Peer kloktijd niet-gesynchroniseerd (gemeenschappelijk voor niet-synchrone server) |
| 7 | 0x40 | Peer stratum uit gebonden |
| 8 | 0x80 | Uitgestelde start/dispersie mislukt grenscontrole |
Dit is voorbeelduitvoer van de opdracht debug ntp-geldigheid:
PCY_PAS1#debug ntp validity
NTP peer validity debugging is on
009585: Mar 1 2012 09:14:32.670 HIVER: NTP: packet from 192.196.113.57 failed validity tests 52
009586: Mar 1 2012 09:14:32.670 HIVER: Authentication failed
009587: Mar 1 2012 09:14:32.670 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009588: Mar 1 2012 09:14:38.210 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009589: Mar 1 2012 09:14:38.210 HIVER: Authentication failed
PCY_PAS1#
009590: Mar 1 2012 09:14:43.606 HIVER: NTP: packet from 163.110.103.27 failed validity tests 14
009591: Mar 1 2012 09:14:43.606 HIVER: Authentication failed
PCY_PAS1#
009592: Mar 1 2012 09:14:48.686 HIVER: NTP: packet from 192.196.113.57 failed validity tests 52
009593: Mar 1 2012 09:14:48.686 HIVER: Authentication failed
009594: Mar 1 2012 09:14:48.686 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009596: Mar 1 2012 09:14:54.222 HIVER: NTP: packet from 163.110.103.35 failed validity tests 14
009597: Mar 1 2012 09:14:54.222 HIVER: Authentication failed
PCY_PAS1#
009598: Mar 1 2012 09:14:54.886 HIVER: NTP: synced to new peer 10.50.38.106
009599: Mar 1 2012 09:14:54.886 HIVER: NTP: 10.50.38.106 synced to new peer
PCY_PAS1#
009600: Mar 1 2012 09:14:59.606 HIVER: NTP: packet from 163.110.103.27 failed validity tests 14
009601: Mar 1 2012 09:14:59.606 HIVER: Authentication failed
PCY_PAS1#
009602: Mar 1 2012 09:15:04.622 HIVER: NTP: packet from 192.196.113.137 failed validity tests 52
009603: Mar 1 2012 09:15:04.622 HIVER: Authentication failed
009604: Mar 1 2012 09:15:04.622 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009605: Mar 1 2012 09:15:10.238 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009606: Mar 1 2012 09:15:10.238 HIVER: Authentication failed
PCY_PAS1#
009607: Mar 1 2012 09:15:15.338 HIVER: NTP: packet from 163.83.23.140 failed validity tests 52
009608: Mar 1 2012 09:15:15.338 HIVER: Authentication failed
009609: Mar 1 2012 09:15:15.338 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009610: Mar 1 2012 09:15:20.402 HIVER: NTP: packet from 192.196.113.92 failed validity tests 74
009611: Mar 1 2012 09:15:20.402 HIVER: Authentication failed
009612: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Clock unsynchronized
009613: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Stratum out of bound
debug van ntp-pakketten
U kunt de opdracht debug ntp-pakketten gebruiken om de tijd te zien die de peer/server u in het ontvangen pakket geeft. De tijd van de lokale machine vertelt ook de tijd die het aan de peer/server in het overgebrachte pakket weet.
| Veld | rcv-pakket | Packet uitreiken |
|---|---|---|
| org | Originator tijdstempel, de servertijd. | Tijdstempel van de Originator (client) toen het pakje werd verzonden. (client maakt een pakje op de server aan.) |
| rec | Tijdstempel op de client wanneer het pakje is ontvangen. | Huidige tijd van client. |
In deze steekproefuitvoer zijn de tijdstempels in het ontvangen pakket van de server en het pakket dat naar een andere server wordt verzonden het zelfde, wat erop wijst dat de client NTP in sync 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 (71.80.83.0)
May 25 02:21:48.182 UTC: ref D3696B38.B722C417 (02:21:44.715 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: org D3696B3C.2EA179BA (02:21:48.182 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: rec D3696B3D.E58DE1BE (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: xmt D3696B3D.E594E7AF (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: inp D3696B3C.2EDFC333 (02:21:48.183 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:22:46.051 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:22:46.051 UTC: rtdel 00C0 (2.930), rtdsp 1C6FA (1777.252), refid 0A0402FE (10.4.2.254)
May 25 02:22:46.051 UTC: ref D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: org D3696B37.E72C75AE (02:21:43.903 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: rec D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: xmt D3696B76.0D43AE7D (02:22:46.051 UTC Fri May 25 2012)
Dit is een voorbeeld van uitvoer wanneer de klokken niet sync zijn. Let op het tijdsverschil tussen het uitgiftepakket en het rcv-pakket. De peer dispersie zal de max waarde van 16000 zijn, en het bereik voor de peer zal 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 (71.80.83.0)
.May 25 02:05:59.011 UTC: ref D3696782.C96FD778 (02:05:54.786 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: rec D3696787.281A963F (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: xmt D3696787.282832C4 (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: inp D3696787.03C63542 (02:05:59.014 UTC Fri May 25 2012)
debug van ntp-sync's en debug van ntp-gebeurtenissen
Het debug ntp sync-opdracht produceert één lijn-uitgangen die aangeven of de kloktijd is gesynchroniseerd of dat de sync is veranderd. De opdracht is over het algemeen ingeschakeld met debug ntp-gebeurtenissen.
De opdracht debug ntp events toont NTP-gebeurtenissen die voorkomen, die u helpen bepalen of een verandering in NTP een probleem veroorzaakt zoals klokken die uit sync gaan. (Met andere woorden als je gelukkig gesynchrone klokken plotseling gek worden, weet je wel om naar een verandering of trigger te zoeken!)
Dit is een voorbeeld van beide debugs. Aanvankelijk waren de client-klokken gesynchroniseerd. De opdracht debug ntp events toont dat een NTP peer stratum verandering heeft plaatsgevonden en de klokken dan uit sync zijn gegaan.
USSP-B33S-SW01#debug ntp sync
NTP clock synchronization debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
USSP-B33S-SW01#debug ntp events
NTP events debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
May 25 02:25:57.620 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:25:57.620 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:25:57.620 UTC: rtdel 00D4 (3.235), rtdsp 26B26 (2418.549), refid 0A0402FE (10.4.2.254)
May 25 02:25:57.620 UTC: ref D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696BF7.E5F91077 (02:24:55.898 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
May 25 02:25:57.620 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:25:57.620 UTC: rtdel 0000 (0.000), rtdsp 000E (0.214), refid 47505300 (71.80.83.0)
May 25 02:25:57.620 UTC: ref D3696C37.D528800E (02:25:59.832 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696C37.E5C7AB3D (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C37.E5D1F273 (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: inp D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:25:59.830 UTC: NTP: clock reset
May 25 02:25:59.830 UTC: NTP: sync change
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:26:05.817 UTC: NTP: xmit packet to 10.1.2.254:
May 25 02:26:05.817 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
May 25 02:26:05.817 UTC: rtdel 00C2 (2.960), rtdsp 38E9C (3557.068), refid 0A0402FE (10.4.2.254)
May 25 02:26:05.817 UTC: ref D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:26:05.817 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: xmt D3696C3D.D12D0565 (02:26:05.817 UTC Fri May 25 2012)
NTP-kloktijd handmatig instellen
De website van Cisco.com waarschuwt:
"De opdracht ntp kloktijd wordt automatisch gegenereerd om de constant veranderende correctiefactor te weerspiegelen wanneer de opdracht van de configuratie van de kopie die start-configuratie wordt ingevoerd om de configuratie in NVRAM op te slaan. Probeer niet handmatig de opdracht ntp kloktijd te gebruiken. Zorg ervoor dat u deze opdrachtregel verwijdert wanneer u configuratiebestanden naar andere apparaten kopieert."
De waarde van de kloktijd is afhankelijk van de hardware. Hij verschilt dus voor elk apparaat.
De opdracht ntp kloktijd wordt automatisch weergegeven in de configuratie wanneer u NTP instelt. Deze opdracht wordt gebruikt om de softwareklok aan te passen. De 'aanpassingswaarde' compenseert het 4 msec-vinkinterval, zodat je, met de kleine aanpassing, 1 seconde hebt aan het einde van het interval.
Als het apparaat heeft berekend dat zijn systeemkloktijd verloren is (misschien moet er een frequentiecompensatie zijn van het basisniveau van de router), voegt het deze waarde automatisch toe aan de systeemkloktijd om zijn synchrone werking te behouden.
De standaard NTP-kloktijd voor een router is 17179869 en wordt in wezen gebruikt om het NTP-proces te starten.
De conversiemethode is 17179869 * 2^(-32) = 0,00399999999957159161567689828125, of ongeveer 4 milliseconden .
De systeemkloktijd voor Cisco 2611-routers (een van de Cisco 2600 Series routers) bleek bijvoorbeeld licht buiten-sync 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 dan de opdracht wr mem te gebruiken om de waarde op te slaan. Dit geeft u een accuraat cijfer voor de volgende herstart en laat NTP toe om sneller te synchroniseren.
Gebruik de opdracht no kloktijd wanneer u de configuratie voor gebruik op een ander apparaat opslaat omdat deze opdracht de kloktijd terugbrengt naar de standaard van dat specifieke apparaat. De werkelijke waarde wordt opnieuw berekend (maar vermindert de nauwkeurigheid van de systeemkloktijd tijdens die herberekeningsperiode).
Onthoud dat deze waarde hardware-afhankelijk is, dus als je een configuratie kopieert en op verschillende apparaten gebruikt, kan je problemen veroorzaken. Cisco is van plan NTP versie 3 te vervangen door versie 4 om dit probleem op te lossen.
Als u niet op de hoogte bent van deze problemen, kunt u besluiten deze waarde handmatig te klikken. Om van het ene apparaat naar het andere te migreren, kunt u besluiten de oude configuratie te kopiëren en op het nieuwe apparaat te plakken. Helaas, omdat het bevel van de ntp kloktijd in het in werking stellen-in werking stellen-vormt en het opstarten-opstarten-akker verschijnt, wordt de klokperiode NTP op het nieuwe apparaat geplakt. Wanneer dit gebeurt, gaat NTP op de nieuwe client altijd uit sync met de server met een hoge verspreidingswaarde per peer.
In plaats daarvan, ontgrendel de NTP kloktijd met de opdracht geen ntp kloktijd, en slaat u de configuratie op. De router berekent uiteindelijk een kloktijd die voor zichzelf geschikt is.
De opdracht ntp kloktijd is niet langer beschikbaar in Cisco IOS-softwarerelease 15.0 of hoger. de parser verwerpt nu de opdracht met de fout:
"%NTP: This configuration command is deprecated."
Dus, bent u niet toegestaan om de klokperiode handmatig te configureren en de kloktijd is niet toegestaan in de run-fig. Aangezien de parser de opdracht afwijst als het in de start-up configuratie configuratie was (in vroegere Cisco IOS versies zoals 12.4), wijst de parser de opdracht af wanneer het de start-up configuratie van het in werking stellen-configureren op opstarten-start-up kopieert.
De nieuwe, vervangingsopdracht is ntp duidelijk drift.
Gerelateerde informatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
17-Aug-2013 |
Eerste vrijgave |
Feedback