Cisco Network Time Protocol (NTP)

NTP (Network Time Protocol) används för att tillåta nätverksenheter att synkronisera sina klockor med en central källklocka. För nätverksenheter som routrar, switchar eller brandväggar är detta mycket viktigt eftersom vi vill se till att loggningsinformation och tidsstämplar har exakt tid och datum. Om du någonsin har nätverksproblem eller blir hackad vill du se till att du vet exakt vad och när det hände.

normalt körs en router eller switch i NTP-klientläge vilket innebär att den kommer att justera klockan baserat på tiden för en NTP-server. I grund och botten beskriver NTP-protokollet algoritmen som NTP-klienterna använder för att synkronisera sina klockor med NTP-servern och paketen som används mellan dem.

ett bra exempel på en NTP-server är ntp.pool.org.Detta är ett kluster av NTP-servrar som många servrar och nätverksenheter använder för att synkronisera sina klockor.

NTP använder ett begrepp som kallas ”stratum” som definierar hur många NTP hoppar bort en enhet är från en författande tidskälla. Till exempel är en enhet med stratum 1 en mycket exakt enhet och kan ha en atomur ansluten till den. En annan NTP-server som använder denna stratum 1-server för att synkronisera sin egen tid skulle vara en stratum 2-enhet eftersom det är en NTP-hop längre bort från källan. När du konfigurerar flera NTP-servrar föredrar klienten NTP-servern med det lägsta stratumvärdet.

Cisco-routrar och switchar kan använda 3 olika NTP-lägen:

• NTP-klientläge.
• NTP-serverläge.
• NTP symmetriskt aktivt läge.

det symmetriska aktiva läget används mellan NTP-enheter för att synkronisera med varandra, det används som en backupmekanism när de inte kan nå den (externa) NTP-servern.

i den återstående av denna lektion, jag kommer att visa hur man konfigurerar NTP på en Cisco-router och växlar.

konfiguration

detta är topologin jag kommer att använda:

routern på toppen kallas ”CoreRouter” och dess kanten av mitt nätverk. Den är ansluten till Internet och kommer att använda en av NTP-servrarna från pool.ntp.org för att synkronisera klockan. Nätverket har också två interna omkopplare som kräver synkroniserade klockor. Båda omkopplarna kommer att bli NTP-klienter i CoreRouter, vilket gör CoreRouter till en NTP-server.

routerkonfiguration

först konfigurerar vi CoreRouter ovanpå. Jag kommer att använda pool.ntp.org som den externa NTP-servern för detta exempel. Vi måste se till att routern kan lösa värdnamn:

CoreRouter(config)#ip name-server 8.8.8.8

Jag kommer att använda Google DNS för detta. Vårt nästa steg är att konfigurera NTP-servern:

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

det var lätt nog, bara ett kommando och vi kommer att synkronisera vår klocka med den offentliga servern. Vi kan verifiera vårt arbete så här:

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

ovan ser vi kommandot show NTP associations som berättar om vår klocka är synkroniserad eller inte. ~ Framför IP-adressen berättar att vi konfigurerade den här servern men vi är inte synkroniserade ännu. Du kan se detta eftersom det inte finns någon * framför IP-adressen och fältet” st ” (stratum) är för närvarande 16.

det finns ytterligare ett kommando som ger oss mer 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.

routern berättar att vi är osynkroniserade och att det inte finns någon referensklocka…vi väntar bara ett par minuter och tittar på dessa kommandon 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

några minuter senare och utgången har ändrats. * Framför IP-adressen berättar att vi har synkroniserat och stratum är 2…Det betyder att den här NTP-servern är ganska nära en pålitlig tidskälla. Fältet” poll ” berättar att vi kommer att försöka synkronisera tiden var 64: e sekund. Låt oss kolla det andra kommandot som vi just såg:

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 klocka har synkroniserats och vårt eget stratum är 3, Det är vettigt eftersom den offentliga stratum-servern har ett stratum av 2 och vi är en ”hop” bort från den.

Cisco-routrar har två olika Klockor, De har en mjukvaruklocka och en hårdvaruklocka och de fungerar separat från varandra. Så här ser du båda klockorna:

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

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

kommandot visa klocka visar mig programvaruklockan medan kommandot Visa kalender ger mig hårdvaruklockan. De två klockorna är inte synkroniserade så det här är något vi borde fixa, du kan göra det så här:

CoreRouter#(config)ntp update-calendar

kommandot NTP update-calendar uppdaterar hårdvaruklockan med tiden för programvaruklockan, här är 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 allt jag ville konfigurera på CoreRouter för nu. Vi måste fortfarande konfigurera två växlar för att synkronisera sina klockor.

Switch Configuration

de två omkopplarna kommer att konfigureras för att använda CoreRouter som NTP-server och jag kommer också att konfigurera dem för att synkronisera sina klockor med varandra. Låt oss konfigurera dem för att använda CoreRouter först:

SW1(config)#ntp server 192.168.123.3

återigen kan det ta några minuter att synkronisera men det här är vad du kommer att 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

klockan för SW1 har synkroniserats och dess stratum är 4. Det är vettigt eftersom det är en ”hop” längre bort från sin NTP-server (CoreRouter). Låt oss göra detsamma för SW2:

SW2(config)#ntp server 192.168.123.3

låt oss vara tålmodiga i några minuter till och det här är vad 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 och SW2 använder nu CoreRouter för att synkronisera sina klockor. Låt oss också konfigurera dem för att använda varandra för synkronisering. Detta är det symmetriska aktiva läget som jag nämnde tidigare, i grund och botten kommer de två omkopplarna att ”hjälpa” varandra att synkronisera … det kan vara användbart om CoreRouter misslyckas någon dag:

SW1(config)#ntp peer 192.168.123.2

SW2(config)#ntp peer 192.168.123.1

efter att ha väntat några minuter ser du att SW1 och SW2 har synkroniserats med varandra:

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

bra allt är nu synkroniserat.

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

är vi klara? Inte riktigt än … det finns några fler saker vi kan göra med NTP. CoreRouter och de två omkopplarna använder unicast (UDP-port 123) för synkronisering men du kan också använda multicast eller broadcast. Låt mig ge dig ett exempel…

Multicast och Broadcast

om du har mer än 20 nätverksenheter eller en router som har begränsat systemminne eller CPU-resurser kanske du vill överväga att använda NTP-sändning eller multicast eftersom det kräver mindre resurser. Vi kan aktivera multicast eller sändning på gränssnittet level.To demonstrera detta Jag kommer att lägga till två routrar under SW1 och SW2 som synkroniserar sig med multicast eller sändning. Så här ser det ut:

jag konfigurerar SW1 för att använda multicast-adress 239.1.1.1 och SW2 skickar NTP-uppdateringar via sändning: