Cisco Network Time Protocol (NTP)

az NTP (Network Time Protocol) arra szolgál, hogy a hálózati eszközök szinkronizálhassák óráikat egy központi forrásórával. Hálózati eszközök, például útválasztók, kapcsolók vagy tűzfalak esetében ez nagyon fontos, mert biztosítani akarjuk, hogy a naplózási információk és időbélyegzők pontos idővel és dátummal rendelkezzenek. Ha valaha is hálózati problémái vannak, vagy feltörik, győződjön meg róla, hogy pontosan tudja, mi és mikor történt.

általában egy útválasztó vagy kapcsoló NTP kliens módban fut, ami azt jelenti, hogy az órát az NTP szerver ideje alapján állítja be. Alapvetően az NTP protokoll azt az algoritmust írja le, amelyet az NTP kliensek használnak az óráik szinkronizálására az NTP szerverrel és a közöttük használt csomagokkal.

jó példa egy NTP szerverre ntp.pool.org. ez az NTP szerverek egy csoportja, amelyet sok szerver és hálózati eszköz használ az órák szinkronizálására.

az NTP egy “stratum” nevű fogalmat használ, amely meghatározza, hogy hány NTP ugrik el egy eszköz egy szerzői időforrástól. Például az 1. rétegű eszköz nagyon pontos eszköz, amelyhez atomóra is csatlakoztatható. Egy másik NTP szerver, amely ezt a stratum 1 szervert használja a saját idejének szinkronizálására, egy stratum 2 eszköz lenne, mert ez egy NTP hop távolabb a forrástól. Több NTP-kiszolgáló konfigurálásakor az ügyfél a legalacsonyabb rétegértékkel rendelkező NTP-kiszolgálót részesíti előnyben.

a Cisco routerek és kapcsolók 3 különböző NTP módot használhatnak:

• NTP kliens mód.
• NTP szerver mód.
• NTP szimmetrikus aktív üzemmód.

a szimmetrikus aktív módot az NTP-eszközök között használják az egymással való szinkronizáláshoz, biztonsági mentési mechanizmusként használják, amikor nem tudják elérni a (külső) NTP-kiszolgálót.

a lecke hátralévő részében bemutatom, hogyan kell konfigurálni az NTP-t egy Cisco útválasztón és kapcsolókon.

konfiguráció

ezt a topológiát fogom használni:

a tetején lévő útválasztó neve “CoreRouter”, és a hálózatom széle. Csatlakozik az internethez, és az egyik NTP-kiszolgálót fogja használni pool.ntp.org szinkronizálni az órát. A hálózatnak két belső kapcsolója is van, amelyek szinkronizált órákat igényelnek. Mindkét kapcsoló a CoreRouter NTP kliensévé válik, így a CoreRouter NTP szerverré válik.

Router konfiguráció

először konfiguráljuk a CoreRouter-t a tetején. Fogom használni pool.ntp.org mint a külső NTP szerver ebben a példában. Meg kell győződnünk arról, hogy az útválasztó képes-e megoldani a gazdagépneveket:

CoreRouter(config)#ip name-server 8.8.8.8

ehhez a Google DNS-t fogom használni. A következő lépés az NTP szerver konfigurálása:

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

ez elég könnyű volt, csak egy parancs, és szinkronizáljuk az óránkat a nyilvános szerverrel. Így tudjuk ellenőrizni a munkánkat:

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

fent látjuk az NTP asszociációk megjelenítése parancsot, amely megmondja, hogy az óránk szinkronizálva van-e vagy sem. Az IP-cím előtti ~ azt mondja nekünk, hogy konfiguráltuk ezt a szervert, de még nem vagyunk szinkronizálva. Ezt azért láthatja, mert az IP-cím előtt nincs*, és az “st” mező (stratum) jelenleg 16.

van még egy parancs, amely további információkat nyújt az NTP konfigurációjáról:

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.

az útválasztó azt mondja nekünk, hogy nem vagyunk szinkronizálva, és hogy nincs referenciaóra…csak néhány percet várunk, és újra megnézzük ezeket a parancsokat:

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

néhány perccel később a kimenet megváltozott. Az IP-cím előtt lévő * azt jelzi, hogy szinkronizálva vagyunk,a réteg pedig 2 … Ez azt jelenti, hogy ez az NTP szerver elég közel van egy megbízható időforráshoz. A “poll” mező azt mondja nekünk, hogy megpróbáljuk szinkronizálni az időt 64 másodpercenként. Ellenőrizzük a másik parancsot, amelyet most láttunk:

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.

az óránk szinkronizálva van, és a saját rétegünk 3, Ennek van értelme, mivel a nyilvános rétegkiszolgáló 2 réteggel rendelkezik, és egy “ugrásra” vagyunk tőle.

a Cisco routerek két különböző órával rendelkeznek, egy szoftverórával és egy hardverórával, és egymástól elkülönítve működnek. Így láthatja mindkét órát:

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

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

a show clock parancs megmutatja nekem a szoftver órát, míg a show calendar parancs megadja a hardver órát. A két óra nincs szinkronban, ezért ezt meg kell javítanunk, így megteheti:

CoreRouter#(config)ntp update-calendar

az NTP update-calendar parancs frissíti a hardver órát a szoftver óra idejével, itt van az eredmény:

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

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

egyelőre csak ennyit akartam konfigurálni a CoreRouter – en. Még be kell állítanunk két kapcsolót, hogy szinkronizáljuk az órájukat.

Switch Configuration

a két kapcsoló úgy lesz konfigurálva, hogy a CoreRouter-t használja NTP szerverként, és úgy is konfigurálom őket, hogy szinkronizálják az óráikat egymással. Állítsuk be őket, hogy először használják a CoreRouter-t:

SW1(config)#ntp server 192.168.123.3

ismét eltarthat néhány percig a szinkronizálás, de ez az, amit látni fog:

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

az SW1 órája szinkronizálva van, rétege pedig 4. Ennek van értelme, mivel ez egy” hop ” távolabb van az NTP szerverétől (CoreRouter). Tegyük ugyanezt az SW2-vel:

SW2(config)#ntp server 192.168.123.3

legyünk türelmesek még néhány percig, és ez az, amit kapunk:

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

az SW1 és az SW2 most CoreRouter-t használ az órák szinkronizálásához. Állítsuk be őket úgy is, hogy egymást használják a szinkronizáláshoz. Ez a szimmetrikus aktív mód, amelyet korábban említettem, alapvetően a két kapcsoló” segít ” egymásnak a szinkronizálásban…ez hasznos lehet abban az esetben, ha a CoreRouter egy nap meghibásodik:

SW1(config)#ntp peer 192.168.123.2

SW2(config)#ntp peer 192.168.123.1

néhány perc várakozás után látni fogja, hogy az SW1 és az SW2 szinkronizált egymással:

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

nagyszerű, most minden szinkronban van.

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

végeztünk? Még nem egészen…van még néhány dolog, amit tehetünk az NTP-vel. A CoreRouter és a két kapcsoló unicast-ot (UDP 123-as port) használ a szinkronizáláshoz, de multicast vagy broadcast is használható. Hadd mondjak egy példát …

Multicast and Broadcast

ha több mint 20 hálózati eszközzel rendelkezik, vagy olyan útválasztóval rendelkezik, amely korlátozott rendszermemóriával vagy CPU-erőforrásokkal rendelkezik, érdemes megfontolni az NTP broadcast vagy a multicast használatát, mivel kevesebb erőforrást igényel. Engedélyezhetjük a multicast vagy a sugárzást az interfészen level.To mutassa be ezt két útválasztót fogok hozzáadni az SW1 és az SW2 alatt, amelyek szinkronizálják magukat a multicast vagy broadcast használatával. Így néz ki:

konfigurálom az SW1-et a 239.1.1.1 multicast cím használatára, és az SW2 NTP-frissítéseket küld a broadcaston keresztül: