Cisco Network Time Protocol (NTP))

NTP (Network Time Protocol) brukes til å tillate nettverksenheter å synkronisere sine klokker med en sentral kilde klokke. For nettverksenheter som rutere, svitsjer eller brannmurer er dette svært viktig fordi vi vil sørge for at logginformasjon og tidsstempler har nøyaktig tid og dato. Hvis du noen gang har nettverksproblemer eller blir hacket, vil du være sikker på at du vet nøyaktig hva og når det skjedde.

Normalt vil en ruter eller bryter kjøre I NTP-klientmodus, noe som betyr at den vil justere klokken basert på TIDSPUNKTET for EN NTP-server. I utgangspunktet BESKRIVER NTP-protokollen algoritmen SOM NTP-klientene bruker til å synkronisere klokkene sine MED NTP-serveren og pakkene som brukes mellom dem.

et godt eksempel PÅ EN NTP-server er ntp.pool.org. Dette er en klynge AV NTP-servere som mange servere og nettverksenheter bruker til å synkronisere sine klokker.

NTP bruker et konsept kalt «stratum» som definerer hvor MANGE NTP humle bort en enhet er fra en forfatter tidskilde. For eksempel er en enhet med stratum 1 en svært nøyaktig enhet og kan ha en atomur festet til den. En ANNEN NTP-server som bruker denne stratum 1-serveren til å synkronisere sin egen tid, ville være en stratum 2-enhet fordi det er EN NTP-hop lenger unna kilden. Når du konfigurerer flere NTP-servere, vil klienten foretrekke NTP-serveren med den laveste stratumverdien.

Cisco-rutere og brytere kan bruke 3 forskjellige NTP-moduser:

• NTP-klientmodus.
• NTP-servermodus.
• NTP symmetrisk aktiv modus.

den symmetriske aktive modusen brukes mellom NTP-enheter for å synkronisere med hverandre, den brukes som en backupmekanisme når de ikke klarer å nå DEN (eksterne) NTP-serveren.

i resten av denne leksjonen vil jeg demonstrere hvordan du konfigurerer NTP på En Cisco-ruter og brytere.

Konfigurasjon

dette er topologien jeg vil bruke:

ruteren på toppen kalles «CoreRouter» og dens kanten av nettverket mitt. DEN er koblet Til Internett og vil bruke EN AV NTP-serverne fra pool.ntp.org slik synkroniserer du klokken. Nettverket har også to interne brytere som krever synkroniserte klokker. Begge bryterne vil bli NTP-klienter Av CoreRouter, og dermed gjøre CoreRouter EN NTP-server.

Ruterkonfigurasjon

først vil Vi konfigurere CoreRouter på toppen. Jeg vil bruke pool.ntp.org SOM den eksterne NTP-serveren for dette eksemplet. Vi må sørge for at ruteren er i stand til å løse vertsnavn:

CoreRouter(config)#ip name-server 8.8.8.8

Jeg vil bruke Google DNS for dette. Vårt neste trinn er å konfigurere NTP-serveren:

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

Det var lett nok, bare en kommando, og vi vil synkronisere klokken vår med den offentlige serveren. Vi kan bekrefte vårt arbeid 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 showet ntp foreninger kommandoen som forteller oss om vår klokke er synkronisert eller ikke. ~ Foran IP-adressen forteller oss at vi konfigurerte denne serveren, men vi er ikke synkronisert ennå. Du kan se dette fordi DET ikke er noen * foran IP-adressen, og» st » – feltet (stratum) er for tiden 16.

det er en kommando som gir oss mer informasjon OM NTP-konfigurasjonen:

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.

ruteren forteller oss at vi er usynkronisert og at det ikke er noen referanseklokke…vi vil bare vente et par minutter og ta en titt på disse kommandoene igjen:

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

Noen minutter senere, og utgangen har endret seg. * Foran IP-adressen forteller oss at vi har synkronisert og stratum er 2…det betyr at DENNE NTP-serveren er ganske nær en pålitelig tidskilde. Feltet «poll» forteller oss at vi vil prøve å synkronisere tiden hvert 64 sekund. La oss sjekke den andre kommandoen vi nettopp så:

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.

vår klokke er synkronisert og vårt eget stratum er 3, det er fornuftig siden den offentlige stratum-serveren har et stratum på 2 og vi er en » hop » vekk fra den.

Cisco-rutere har to forskjellige klokker, de har en programvareklokke og en maskinvareklokke og de opererer separat fra hverandre. Slik ser du begge klokkene:

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 klokke viser meg programvareklokken mens kommandoen vis kalender gir meg maskinvareklokken. De to klokkene er ikke synkronisert, så dette er noe vi bør fikse, du kan gjøre det slik:

CoreRouter#(config)ntp update-calendar

kommandoen ntp update-calendar vil oppdatere maskinvareklokken med tiden på programvareklokken, 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 er alt jeg ønsket å konfigurere På CoreRouter for nå. Vi må fortsatt konfigurere to brytere for å synkronisere klokkene sine.

Bryterkonfigurasjon

de to bryterne vil bli konfigurert til å bruke CoreRouter som NTP-server, og jeg vil også konfigurere dem til å synkronisere klokkene med hverandre. La oss konfigurere dem til å bruke CoreRouter først:

SW1(config)#ntp server 192.168.123.3

igjen kan det ta noen minutter å synkronisere, men dette er hva 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

klokken PÅ SW1 er synkronisert og dens stratum er 4. Dette er fornuftig siden det er en » hop » lenger unna SIN NTP server (CoreRouter). La OSS gjøre DET SAMME FOR SW2:

SW2(config)#ntp server 192.168.123.3

La oss være tålmodige i noen minutter, og dette er hva 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

SW1 OG SW2 bruker Nå CoreRouter å synkronisere sine klokker. La oss også konfigurere dem til å bruke hverandre for synkronisering. Dette er den symmetriske aktive modusen jeg nevnte før, i utgangspunktet vil de to bryterne» hjelpe » hverandre til å synkronisere…:

SW1(config)#ntp peer 192.168.123.2

SW2(config)#ntp peer 192.168.123.1

etter å ha ventet noen minutter vil du se AT SW1 OG SW2 har synkronisert med hverandre:

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

Flott alt er nå synkronisert.

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 ferdige? Ikke helt ennå … det er noen flere ting vi kan gjøre med NTP. CoreRouter og de to bryterne bruker unicast (UDP port 123) for synkronisering, men du kan også bruke multicast eller broadcast. La meg gi deg et eksempel…

Multicast Og Broadcast

hvis du har mer enn 20 nettverksenheter Eller en ruter som har begrenset systemminne eller CPU-ressurser, vil du kanskje vurdere Å bruke NTP-kringkasting eller multicast som det krever mindre ressurser. Vi kan aktivere multicast eller kringkasting på grensesnittet level.To demonstrer dette jeg vil legge til to rutere UNDER SW1 OG SW2 som vil synkronisere seg ved hjelp av multicast eller broadcast. Slik ser det ut:

JEG vil konfigurere SW1 å bruke multicast-adresse 239.1.1.1 OG SW2 vil sende NTP oppdateringer via kringkasting: