Cisco netværk tid protokol (NTP)

NTP (Netværkstidsprotokol) bruges til at tillade netværksenheder at synkronisere deres ure med et centralt kildeur. For netværksenheder som routere, kontakter eller brandvægge er dette meget vigtigt, fordi vi vil sikre os, at logningsoplysninger og tidsstempler har den nøjagtige tid og dato. Hvis du nogensinde har netværksproblemer eller bliver hacket, vil du sikre dig, at du ved nøjagtigt, hvad og hvornår det skete.

normalt kører en router eller kontakt i NTP-klienttilstand, hvilket betyder, at den justerer sit ur baseret på tidspunktet for en NTP-server. Grundlæggende beskriver NTP-protokollen den algoritme, som NTP-klienterne bruger til at synkronisere deres ure med NTP-serveren og de pakker, der bruges mellem dem.

et godt eksempel på en NTP-server er ntp.pool.org. dette er en klynge af NTP-servere, som mange servere og netværksenheder bruger til at synkronisere deres ure.

NTP bruger et koncept kaldet “stratum”, der definerer, hvor mange NTP humle væk en enhed er fra en forfattertidskilde. For eksempel er en enhed med stratum 1 en meget nøjagtig enhed og kan have et atomur fastgjort til det. En anden NTP-server, der bruger denne stratum 1-server til at synkronisere sin egen tid, ville være en stratum 2-enhed, fordi det er et NTP-hop længere væk fra kilden. Når du konfigurerer flere NTP-servere, foretrækker klienten NTP-serveren med den laveste stratumværdi.

Cisco routere og afbrydere kan bruge 3 forskellige NTP-tilstande:

• NTP-klienttilstand.
• NTP-servertilstand.
• NTP symmetrisk aktiv tilstand.

den symmetriske aktive tilstand bruges mellem NTP-enheder til at synkronisere med hinanden, den bruges som en backupmekanisme, når de ikke kan nå den (eksterne) NTP-server.

i den resterende del af denne lektion vil jeg demonstrere, hvordan man konfigurerer NTP på en Cisco-router og kontakter.

konfiguration

dette er topologien, jeg vil bruge:

routeren på toppen kaldes “CoreRouter” og dens kanten af mit netværk. Det er forbundet til internettet og vil bruge en af NTP-serverne fra pool.ntp.org for at synkronisere sit ur. Netværket har også to interne kontakter, der kræver synkroniserede ure. Begge kontakter bliver NTP-klienter til CoreRouter, hvilket gør CoreRouter til en NTP-server.

routerkonfiguration

først konfigurerer vi CoreRouter på toppen. Jeg vil bruge pool.ntp.org som den eksterne NTP-server til dette eksempel. Vi skal sørge for, at routeren er i stand til at løse værtsnavne:

CoreRouter(config)#ip name-server 8.8.8.8

Jeg vil bruge Google DNS til dette. Vores næste trin er at konfigurere NTP-serveren:

CoreRouter(config)#ntp server pool.ntp.org

det var let nok, kun en kommando, og vi synkroniserer vores ur med den offentlige server. Vi kan bekræfte vores arbejde som dette:

CoreRouter#show ntp associations address ref clock st when poll reach delay offset disp ~146.185.130.223 .INIT. 16 - 64 0 0.000 0.000 16000. * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

ovenfor ser vi kommandoen Vis NTP-foreninger, der fortæller os, om vores ur er synkroniseret eller ej. ~ Foran IP-adressen fortæller os, at vi konfigurerede denne server, men vi er ikke synkroniseret endnu. Du kan se dette, fordi der ikke er nogen * foran IP-adressen, og “st” – feltet (stratum) er i øjeblikket 16.

der er endnu en kommando, der giver os mere information om NTP-konfigurationen:

CoreRouter#show ntp statusClock is unsynchronized, stratum 16, no reference clocknominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)clock offset is 0.0000 msec, root delay is 0.00 msecroot dispersion is 0.16 msec, peer dispersion is 0.00 msecloopfilter state is 'FSET' (Drift set from file), drift is 0.000000000 s/ssystem poll interval is 64, never updated.

routeren fortæller os, at vi er usynkroniserede, og at der ikke er noget referenceur…vi venter bare et par minutter og kigger på disse kommandoer igen:

CoreRouter#show ntp associations address ref clock st when poll reach delay offset disp*~146.185.130.223 193.79.237.14 2 26 64 1 10.857 -5.595 7937.5 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

et par minutter senere, og output er ændret. * Foran IP-adressen fortæller os, at vi har synkroniseret, og stratumet er 2…Det betyder, at denne NTP-server er temmelig tæt på en pålidelig tidskilde. Feltet” afstemning ” fortæller os, at vi vil forsøge at synkronisere tiden hvert 64.sekund. Lad os kontrollere den anden kommando, som vi lige har set:

CoreRouter#show ntp status Clock is synchronized, stratum 3, reference is 146.185.130.22nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24reference time is D76513B4.66A4CDA6 (12:40:20.400 UTC Mon Jul 7 2014)clock offset is -5.5952 msec, root delay is 13.58 msecroot dispersion is 7966.62 msec, peer dispersion is 7937.50 msecloopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000000018 s/ssystem poll interval is 64, last update was 43 sec ago.

vores ur er blevet synkroniseret, og vores eget stratum er 3, Det giver mening, da den offentlige stratumserver har et stratum på 2, og vi er et “hop” væk fra det.

Cisco routere har to forskellige ure, de har et programur og et udstyrsur, og de fungerer adskilt fra hinanden. Sådan ser du begge ure:

CoreRouter#show clock 12:41:25.197 UTC Mon Jul 7 2014

CoreRouter#show calendar 12:43:24 UTC Mon Jul 7 2014

kommandoen Vis ur viser mig programmeluret, mens kommandoen Vis kalender giver mig maskinuret. De to ure er ikke synkroniseret, så det er noget, vi skal rette, Du kan gøre det sådan:

CoreRouter#(config)ntp update-calendar

NTP-opdateringskalenderkommandoen opdaterer maskinens ur med tiden for programuret, her er resultatet:

CoreRouter#show clock 12:42:31.853 UTC Mon Jul 7 2014

CoreRouter#show calendar 12:42:30 UTC Mon Jul 7 2014

det var alt, hvad jeg ønskede at konfigurere på CoreRouter for nu. Vi er stadig nødt til at konfigurere to kontakter til at synkronisere deres ure.

skift konfiguration

de to kontakter vil blive konfigureret til at bruge CoreRouter som NTP-server, og jeg vil også konfigurere dem til at synkronisere deres ure med hinanden. Lad os konfigurere dem til at bruge CoreRouter først:

SW1(config)#ntp server 192.168.123.3

endnu en gang kan det tage et par minutter at synkronisere, men det er hvad du vil se:

SW1#show ntp associations address ref clock st when poll reach delay offset disp*~192.168.123.3 146.185.130.223 3 21 64 1 2.5 1.02 15875. * master (synced), # master (unsynced), + selected, - candidate, ~ configured

SW1#show ntp status Clock is synchronized, stratum 4, reference is 192.168.123.3nominal freq is 119.2092 Hz, actual freq is 119.2089 Hz, precision is 2**18reference time is D765271D.D6021302 (14:03:09.835 UTC Mon Jul 7 2014)clock offset is 1.0229 msec, root delay is 14.31 msecroot dispersion is 16036.00 msec, peer dispersion is 15875.02 msec

uret på S1 er blevet synkroniseret, og dets lag er 4. Dette giver mening, da det er et “hop” længere væk fra sin NTP-server (CoreRouter). Lad os gøre det samme for S2:

SW2(config)#ntp server 192.168.123.3

lad os være tålmodige i et par minutter mere, og det er det, vi får:

SW2#show ntp associations address ref clock st when poll reach delay offset disp*~192.168.123.3 146.185.130.223 3 17 64 37 3.4 1.89 875.8 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

SW2#show ntp status Clock is synchronized, stratum 4, reference is 192.168.123.3nominal freq is 119.2092 Hz, actual freq is 119.2084 Hz, precision is 2**18reference time is D765274D.D51A0546 (14:03:57.832 UTC Mon Jul 7 2014)clock offset is 1.8875 msec, root delay is 15.18 msecroot dispersion is 1038.39 msec, peer dispersion is 875.84 msec

S1 og S2 bruger nu CoreRouter til at synkronisere deres ure. Lad os også konfigurere dem til at bruge hinanden til synkronisering. Dette er den symmetriske aktive tilstand, jeg nævnte før, dybest set vil de to kontakter “hjælpe” hinanden med at synkronisere…dette kan være nyttigt, hvis CoreRouter fejler en dag:

SW1(config)#ntp peer 192.168.123.2

SW2(config)#ntp peer 192.168.123.1

efter at have ventet et par minutter vil du se, at S1 og S2 er synkroniseret med hinanden:

SW1#show ntp associations address ref clock st when poll reach delay offset disp*~192.168.123.3 146.185.130.223 3 59 64 37 3.0 -0.74 877.4+~192.168.123.2 192.168.123.3 4 50 128 376 2.2 -2.04 1.3 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

SW2#show ntp associations address ref clock st when poll reach delay offset disp*~192.168.123.3 146.185.130.223 3 45 128 377 2.9 1.95 1.0 ~192.168.123.1 192.168.123.3 4 67 1024 376 1.8 2.40 1.4 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

stort alt er nu synkroniseret.

hostname CoreRouter!interface FastEthernet0/0 ip address 192.168.123.3 255.255.255.0!ip name-server 8.8.8.8!ntp server pool.ntp.orgntp update-calendar!end

hostname SW1!interface FastEthernet0/24 ip address 192.168.123.1 255.255.255.0!ntp server 192.168.123.3ntp peer 192.168.123.2!end

hostname SW2!interface FastEthernet0/24 ip address 192.168.123.2 255.255.255.0!ntp server 192.168.123.3ntp peer 192.168.123.1!end

er vi færdige? Ikke helt endnu … der er et par flere ting, vi kan gøre med NTP. CoreRouter og de to kontakter bruger unicast (UDP-port 123) til synkronisering, men du kan også bruge multicast eller broadcast. Lad mig give dig et eksempel…

Multicast og Broadcast

hvis du har mere end 20 netværksenheder eller en router, der har begrænset systemhukommelse eller CPU-ressourcer, kan du overveje at bruge NTP broadcast eller multicast, da det kræver mindre ressourcer. Vi kan aktivere multicast eller udsende på grænsefladen level.To jeg vil tilføje to routere under S1 og S2, der synkroniserer sig selv ved hjælp af multicast eller broadcast. Sådan ser det ud:

jeg konfigurerer S1 til at bruge multicast-adresse 239.1.1.1 og S2 sender NTP-opdateringer gennem udsendelse: