Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Voorbeeldsymptomen van NTP-problemen

NTP-opdrachten weergeven

NTP-associaties tonen

NTP-peer tonen

Probleemoplossing voor NTP met vManager- en Packet Capture Tools

Controleer de uitgang met Simulate Flows op vManager

TCP/CDump van vEdge verzamelen

Wireshark Capture uitvoeren vanuit vManager

Gemeenschappelijke NTP-problemen

NTP-pakketten niet ontvangen

Verlies van Synchonisatie

De klok op het apparaat is handmatig ingesteld

Referenties en verwante informatie

Inleiding

Dit document beschrijft hoe u problemen met Network Time Protocol (NTP) kunt oplossen met ntp-opdrachten en pakketopnametools op vEdge-platforms tonen.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

Dit document is niet beperkt tot specifieke softwareversies of vEdge-modellen.

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.

Voorbeeldsymptomen van NTP-problemen

Het verlies van NTP-synchronisatie naar een vEdge kan op een paar verschillende manieren tot uiting komen, bijvoorbeeld:

- Onjuiste tijd in weergave van de klokuitvoer op het apparaat.

- Certificaten worden als ongeldig beschouwd vanwege een onjuiste tijd buiten het geldigheidsbereik.

- Onjuiste tijdstempels in logs.

NTP-opdrachten weergeven

Om met isolatie van NTP problemen te beginnen, moet u het gebruik van en de output van twee belangrijke bevelen begrijpen:

- toon ntp verenigingen

- toon ntp peer

Nadere details over specifieke opdrachten vindt u in de SD-WAN Command Reference.

NTP-associaties tonen

vedge1# show ntp associations

LAST

IDX  ASSOCID  STATUS  CONF  REACHABILITY  AUTH  CONDITION  EVENT      COUNT

-----------------------------------------------------------------------------

1    56368    8011    yes   no            none  reject     mobilize   1

2    56369    911a    yes   yes           none  falsetick  sys_peer   1

3    56370    9124    yes   yes           none  falsetick  reachable  2

IDX

nummer van lokale index

ASSOCID

associatie-ID

STATUS

peer-statuswoord (in hexadecimaal)

CONF

configuratie (persistent of efemeer)

BEREIKBAARHEID

bereikbaarheid (ja of nee)

AUTH

authentificatie (ok, ja, slecht, of niets)

TOESTAND

selectiestatus

EVENEMENT

laatste evenement voor deze peer

TELLEN

telling van gebeurtenissen

NTP-peer tonen

vedge1# show ntp peer | tab

INDEX  REMOTE          REFID     ST  TYPE  WHEN  POLL  REACH  DELAY    OFFSET   JITTER

----------------------------------------------------------------------------------------

1      192.168.18.201  .STEP.    16  u     37    1024  0      0.000    0.000    0.000

2      x10.88.244.1    LOCAL(1)  2   u     7     64    377    108.481  140.642  20.278

3      x172.18.108.15  .GPS.     1   u     66    64    377    130.407  -24883.  55.334

INDEXEREN

nummer van lokale index

AFGELEGEN

NTP-serveradres

RENOVEREN

Huidige bron van synchronisatie via de peer

ST

laag

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.

TYPE

type

WANNEER

De tijd sinds het laatste NTP-pakket is ontvangen van een peer wordt in seconden gerapporteerd. Deze waarde moet lager zijn dan het poll interval.

ENQUÊTE

opiniepeilingsinterval (seconden)

BEREIK

bereik, zoals gespecificeerd door octale waarde op basis van de laatste 8 verbindingen

377 (1 1 1 1 1 1 1 1) - De laatste 8 waren allemaal OK

376 (1 1 1 1 1 1 1 0) - Laatste aansluiting slecht

....

177 (0 1 1 1 1 1 1 1 1) - Oudste verbinding was slecht, allemaal sinds goed

en zo verder

VERTRAGING

De vertraging van de ronde reis naar peer wordt gemeld in milliseconden. Om de kloktijd nauwkeuriger in te stellen, wordt deze vertraging in aanmerking genomen wanneer de kloktijd is ingesteld.

OFFSET

offset (in milliseconden)

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.

JITTER

jitter (in milliseconden)

Probleemoplossing voor NTP met vManager- en Packet Capture Tools

Controleer de uitgang met Simulate Flows op vManager

1. Kies het dashboard van het netwerkapparaat via monitor > Netwerk

2. Kies de gewenste vEdge.

3. Klik op de optie Problemen oplossen, gevolgd door Stromen simuleren.

4. Specificeer bron VPN en interface van drop-downs, plaats bestemming IP, en plaats toepassing als ntp.

5. Klik op Simuleren.

Dit geeft het verwachte doorstuurgedrag voor NTP-verkeer vanuit de vEdge.

TCP/CDump van vEdge verzamelen

Wanneer NTP-verkeer door het besturingsplane van de vEdge gaat, kan dit via TCPdump worden opgenomen.  De matchvoorwaarde zou de standaard UDP-poort 123 moeten gebruiken om specifiek voor NTP-verkeer te filteren.

tcpdump vpn 0 opties "dst port 123"

vedge1# tcpdump interface ge0/0 options "dst port 123"

tcpdump -p -i ge0_0 -s 128 dst port 123 in VPN 0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on ge0_0, link-type EN10MB (Ethernet), capture size 128 bytes

19:05:44.364567 IP 192.168.19.55.ntp > 10.88.244.1.ntp: NTPv4, Client, length 48

19:05:44.454385 IP 10.88.244.1.ntp > 192.168.19.55.ntp: NTPv4, Server, length 48

19:05:45.364579 IP 192.168.19.55.ntp > 172.18.108.15.ntp: NTPv4, Client, length 48

19:05:45.373547 IP 172.18.108.15.ntp > 192.168.19.55.ntp: NTPv4, Server, length 48

19:06:52.364470 IP 192.168.19.55.ntp > 10.88.244.1.ntp: NTPv4, Client, length 48

19:06:52.549536 IP 10.88.244.1.ntp > 192.168.19.55.ntp: NTPv4, Server, length 48

19:06:54.364486 IP 192.168.19.55.ntp > 172.18.108.15.ntp: NTPv4, Client, length 48

19:06:54.375065 IP 172.18.108.15.ntp > 192.168.19.55.ntp: NTPv4, Server, length 48

Voeg de breedsprakige flag -v toe om de tijdstempels te decoderen van binnen de NTP-pakketten.

tcpdump vpn 0 opties "dst poort 123 -v"

vedge1# tcpdump interface ge0/0 options "dst port 123 -n -v"

tcpdump -p -i ge0_0 -s 128 dst port 123 -n -v in VPN 0

tcpdump: listening on ge0_0, link-type EN10MB (Ethernet), capture size 128 bytes

19:10:13.364515 IP (tos 0xb8, ttl 64, id 62640, offset 0, flags [DF], proto UDP (17), length 76)

192.168.19.55.123 > 192.168.18.201.123: NTPv4, length 48

Client, Leap indicator: clock unsynchronized (192), Stratum 3 (secondary reference), poll 6 (64s), precision -24

Root Delay: 0.103881, Root dispersion: 1.073425, Reference-ID: 10.88.244.1

Reference Timestamp:  3889015198.468340729 (2023/03/28 17:59:58)

Originator Timestamp: 3889019320.559000091 (2023/03/28 19:08:40)

Receive Timestamp:    3889019348.377538353 (2023/03/28 19:09:08)

Transmit Timestamp:   3889019413.364485614 (2023/03/28 19:10:13)

Originator - Receive Timestamp:  +27.818538262

Originator - Transmit Timestamp: +92.805485523

19:10:13.365092 IP (tos 0xc0, ttl 255, id 7977, offset 0, flags [none], proto UDP (17), length 76)

192.168.18.201.123 > 192.168.19.55.123: NTPv4, length 48

Server, Leap indicator:  (0), Stratum 8 (secondary reference), poll 6 (64s), precision -10

Root Delay: 0.000000, Root dispersion: 0.002166, Reference-ID: 127.127.1.1

Reference Timestamp:  3889019384.881000144 (2023/03/28 19:09:44)

Originator Timestamp: 3889019413.364485614 (2023/03/28 19:10:13)

Receive Timestamp:    3889019385.557000091 (2023/03/28 19:09:45)

Transmit Timestamp:   3889019385.557000091 (2023/03/28 19:09:45)

Originator - Receive Timestamp:  -27.807485523

Originator - Transmit Timestamp: -27.807485523

Wireshark Capture uitvoeren vanuit vManager

Als packet captures zijn ingeschakeld vanuit vManager, kan NTP-verkeer ook op deze manier rechtstreeks worden opgenomen in een bestand dat leesbaar is door Wireshark.

1. Kies het dashboard van het netwerkapparaat via monitor > Netwerk

2. Kies de gewenste vEdge.

3. Klik op de optie Problemen oplossen, gevolgd door Packet Capture.

4. Kies VPN 0 en de buiteninterface in de uitrolmenu's.

5. Klik op Traffic Filter. Hier kunt u bestemmingshaven 123 en indien gewenst, een specifieke bestemmingsserver specificeren.
Opmerking: met Filter op IP-adres worden alleen pakketten in één richting opgenomen, omdat het IP-filter op bron of bestemming is ingesteld.  Omdat de bestemmingslaag 4 poort 123 in beide richtingen is, filter door de poort alleen om bidirectioneel verkeer op te nemen.

6. Klik op Start.

vManager communiceert nu met vEdge om een pakketopname te maken voor 5 minuten of totdat de 5 MB buffer is opgevuld, afhankelijk van wat het eerst komt. Na voltooiing kan die opname worden gedownload voor review.

Gemeenschappelijke NTP-problemen

NTP-pakketten niet ontvangen

Packet Capture toont uitgaande pakketten die naar de geconfigureerde server(s) zijn verzonden, maar er worden geen antwoorden ontvangen.

vedge1# tcpdump interface ge0/0 options "dst 192.168.18.201 && dst port 123 -n"

tcpdump -p -i ge0_0 -s 128 dst 192.168.18.201 && dst port 123 -n in VPN 0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on ge0_0, link-type EN10MB (Ethernet), capture size 128 bytes

14:24:49.364507 IP 192.168.19.55.123 > 192.168.18.201.123: NTPv4, Client, length 48

14:25:55.364534 IP 192.168.19.55.123 > 192.168.18.201.123: NTPv4, Client, length 48

14:27:00.364521 IP 192.168.19.55.123 > 192.168.18.201.123: NTPv4, Client, length 48

^C

3 packets captured

3 packets received by filter

0 packets dropped by kernel

Zodra u bevestigt dat NTP-pakketten niet worden ontvangen, kunt u:

- Controleer of NTP goed is geconfigureerd.

- Als het verkeer een tunnel in VPN 0 doorkruist, zorg ervoor dat allow-service ntp of allow-service all is ingeschakeld onder de tunnelinterface.

- Controleer of NTP is geblokkeerd door een toegangslijst of intermediair apparaat.

- Controleer op routeringsproblemen tussen de NTP-bron en de bestemming.

Verlies van Synchonisatie

Er kan geen synchronisatie-effect 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 pakket aanwezig is, omdat het niet weet hoe lang het duurde voordat het pakket aankwam.

Als er een verstopte link in het pad is die buffering veroorzaakt, worden pakketten uitgesteld als ze naar de NTP-client komen.

Als u verlies van synchronisatie ervaart, moet u de koppelingen controleren:

- Is er congestie/overtekening op het pad?

- Zijn er gevallen pakketten geobserveerd?

- Is er sprake van encryptie?

De bereikwaarde in show ntp peer kan wijzen op verlies van NTP verkeer.  Als de waarde minder dan 377 is, worden de pakketten met tussenpozen ontvangen en de cliënt gaat uit synchronisatie uit.

De klok op het apparaat is handmatig ingesteld

De klokwaarden die van NTP zijn geleerd, kunnen worden overschreven via de opdracht Klokset.  Als dit gebeurt, worden de offset-waarden voor alle peers aanzienlijk verhoogd.

vedge1# show ntp peer | tab

INDEX  REMOTE           REFID     ST  TYPE  WHEN  POLL  REACH  DELAY    OFFSET   JITTER

-----------------------------------------------------------------------------------------

1      x10.88.244.1     LOCAL(1)  2   u     40    64    1      293.339  -539686  88.035

2      x172.18.108.15   .GPS.     1   u     39    64    1      30.408   -539686  8.768

3      x192.168.18.201  LOCAL(1)  8   u     38    64    1      5.743    -539686  2.435

Veelzijdige opnamen laten ook zien dat de referentie-tijdstempels en originator-tijdstempels zich niet uitlijnen.

vedge1# tcpdump interface ge0/0 options "src 192.168.18.201 && dst port 123 -n -v"

tcpdump -p -i ge0_0 -s 128 src 192.168.18.201 && dst port 123 -n -v in VPN 0

tcpdump: listening on ge0_0, link-type EN10MB (Ethernet), capture size 128 bytes

00:01:28.156796 IP (tos 0xc0, ttl 255, id 8542, offset 0, flags [none], proto UDP (17), length 76)

192.168.18.201.123 > 192.168.19.55.123: NTPv4, length 48

Server, Leap indicator:  (0), Stratum 8 (secondary reference), poll 6 (64s), precision -10

Root Delay: 0.000000, Root dispersion: 0.002365, Reference-ID: 127.127.1.1

Reference Timestamp:  3889091263.881000144 (2023/03/29 15:07:43)

Originator Timestamp: 133810392.155976055 (2040/05/05 00:01:28)

Receive Timestamp:    3889091277.586000096 (2023/03/29 15:07:57)

Transmit Timestamp:   3889091277.586000096 (2023/03/29 15:07:57)

Originator - Receive Timestamp:  -539686410.569975959

Originator - Transmit Timestamp: -539686410.569975959

^C

1 packet captured

1 packet received by filter

0 packets dropped by kernel

Om de vEdge te dwingen de voorkeur voor NTP als tijdbron te hervatten, de configuratie onder systeem ntp te verwijderen, vastleggen, opnieuw toevoegen en opnieuw vastleggen.

Referenties en verwante informatie

- Problemen met NTP-problemen oplossen en debuggen (Cisco IOS-apparaten)

- Cisco SD-WAN opdrachtreferentie

- NTP status verifiëren met de show ntp associaties Opdracht