Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

NTP-opdrachten weergeven

toon ntp vereniging

ntp-associatiedetail tonen

ntp-status tonen

Probleemoplossing voor NTP met debuggen

NTP-pakketten niet ontvangen

NTP-pakketten niet verwerkt

Verlies van synchronisatie

debug ntp-geldigheid

debug ntp-pakketten

debug ntp sync en debug ntp gebeurtenissen

NTP-klokperiode handmatig instellen

Gerelateerde informatie

Inleiding

Dit document beschrijft hoe u problemen met Network Time Protocol (NTP) kunt oplossen met  debug  opdrachten en de  show ntp  uit.

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: de uitvoertolk ondersteunt bepaalde showopdrachten. Gebruik de Output Interpreter Tool om een analyse te bekijken van de output van de opdracht show. Alleen geregistreerde Cisco-gebruikers kunnen toegang krijgen tot interne tools en informatie.

toon ntp vereniging

Een NTP-associatie kan een peer-associatie zijn (het ene systeem is bereid om te synchroniseren met het andere systeem of het andere systeem te laten synchroniseren) of een serverassociatie (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:

* gesynchroniseerd met deze peer

# Bijna gesynchroniseerd met deze peer

+ Peer geselecteerd voor mogelijke synchronisatie

- Peer is een kandidaat voor selectie

~ Peer is statisch geconfigureerd

toespraak

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 primaire routers, switches of servers binnen het lokale netwerk waarschijnlijk zijn. Voor de laatste vier inzendingen is de referentieklok een publiek IP, zodat hun primarys 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:

- 377 octal = 11111111 binair getal, dat het NTP-proces aangeeft dat de laatste acht pakketten ontvangen zijn.

- 0 octal = 00000000, wat aangeeft dat het NTP-proces geen pakket heeft ontvangen.

- 1 octal = 00000001, wat aangeeft dat het NTP-proces alleen het laatste pakket heeft ontvangen.

- 357 octal = 11101111, dat het pakket aangeeft voordat de laatste vier pakketten verloren zijn gegaan.

Reach is een goede indicator van of NTP-pakketten worden weggelaten vanwege een slechte link, CPU-problemen en andere intermitterende problemen.

Unit Converter is een online unit converter voor deze en vele andere conversies.

opschorten

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

~10.50.44.69  10.50.36.106   5  21231  1024     0    3.8   -4.26  16000.

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

Dit is een voorbeeld van uitvoer van de show ntp associatiedetailopdracht:

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 synchronisatie 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:

Testen

Masker

Toelichting

1

0x01

Dubbel ontvangen pakket

2

0x02

Bogus-pakket ontvangen

3

0x04

Protocol niet gesynchroniseerd

4

0x08

Grenscontrole van peer-vertraging/dispersie is mislukt

5

0x10

Verificatie door peers mislukt

6

0x20

Peer klok niet-gesynchroniseerd (gebruikelijk voor niet-gesynchroniseerde server)

7

0x40

Peer stratum niet geconsolideerd

8

0x80

Grenscontrole van wortelvertraging/dispersie is mislukt

Packet data is geldig als tests 1 tot en met 4 succesvol zijn. De gegevens worden dan gebruikt om offset, vertraging en dispersie te berekenen.

De pakketheader is geldig als tests 5 tot 8 worden doorgegeven. 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 naar deze peer of van de peer naar 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 'disp' onder Show up associatie voor meer details.

sync-dist.

Dit is een schatting van het maximale verschil tussen de tijd op stratum 0 bron en de tijd gemeten door de klant; het bestaat uit componenten voor ronde reistijd, systeemprecisie, en klokverloop sinds de laatste werkelijke gelezen van de stratum bron.

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.

opschorten

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)

rcv time D36968B7.A2F44E2C (02:11:03.636 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

filtoffset

filteren

Dit is de ronde reisvertraging in milliseconden van elk monster.

Dit is de klokoffset in milliseconden van elke steekproef.

Dit is de geschatte fout 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

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

Deze acht steekproeven corresponderen met de waarde van het bereik veld, dat toont of de lokale client de laatste acht NTP-pakketten heeft ontvangen.

ntp-status tonen

Dit is een voorbeeld van output van het bevel van de show ntp 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 in het vak NTP-associatiedetails tonen 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:

1. NTP synchroniseert nooit met een machine die zelf niet gesynchroniseerd is.

1. NTP vergelijkt de tijd die door meerdere machines wordt gerapporteerd en synchroniseert niet met een machine waarvan de tijd aanzienlijk verschilt van de andere, zelfs als haar stratum lager is.

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 commando's voordat u debug commando's 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.

1. ACL 101 maken:

access-list 101 permit udp any any eq 123

access-list 101 permit udp any eq 123 any
NTP-pakketten hebben doorgaans een bron- en doelpoort van 123, zodat dit helpt:

permit udp any eq 123 any eq 123

2. Gebruik deze ACL om de uitvoer van de opdracht debug ip-pakket te beperken:

debug ip packet 101

3. 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 correspondentingang die door debug ntp-pakketten wordt gegenereerd.

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 van 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 op een manier 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 SNTP (Simple Network Time Protocol) 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.

debug ntp-geldigheid

De debug ntp validiteitsopdracht geeft aan of het NTP-pakket is mislukt en of de validiteitscontroles zijn mislukt 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 van peer-vertraging/dispersie is mislukt

5

0x10

Verificatie door peers mislukt

6

0x20

Peer klok niet-gesynchroniseerd (gebruikelijk voor niet-gesynchroniseerde server)

7

0x40

Peer stratum niet geconsolideerd

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

debug ntp-pakketten

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

Het debug ntp synchronisatiebevel produceert one-line outputs die tonen of de kloktijd gesynchroniseerd is of de sync is veranderd. De opdracht is over het algemeen ingeschakeld met debug ntp-gebeurtenissen.

De debug ntp gebeurtenissen commando toont alle NTP gebeurtenissen die voorkomen, die u helpt om te bepalen of een verandering in de 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 debug ntp gebeurtenissen commando laat zien dat een NTP peer stratum wijziging heeft plaatsgevonden, en de klokken toen uit sync.

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 stellen-configuratie opstarten-configuratie is ingegaan om de configuratie aan NVRAM te bewaren. Probeer niet om de opdracht voor de ntp-klokperiode 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 einde 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.

Opmerking: 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 van de ntp klok-periode wanneer u de configuratie voor gebruik op een ander apparaat opslaat omdat dit bevel de klok-periode 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 de 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-software versie 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

- Support Forum Thread: NTP klokperiode niet geconfigureerd

- Network Time Protocol: Best Practices-witboek

- Network Time Protocol (NTP) troubleshooten

- Cisco technische ondersteuning en downloads