Cisco Network Time Protocol (NTP)

NTP (Network Time Protocol) wordt gebruikt om netwerkapparaten toe te staan hun klokken te synchroniseren met een centrale bronklok. Voor netwerkapparaten zoals routers, switches of firewalls is dit erg belangrijk omdat we ervoor willen zorgen dat loggegevens en tijdstempels de juiste tijd en datum hebben. Als je ooit netwerkproblemen hebt of gehackt wordt, wil je er zeker van zijn dat je precies weet wat en wanneer het gebeurde.

normaal gesproken draait een router of switch in NTP-clientmodus, wat betekent dat het zijn klok aanpast op basis van de tijd van een NTP-server. In principe beschrijft het NTP-protocol het algoritme dat de NTP-clients gebruiken om hun klokken te synchroniseren met de NTP-server en de pakketten die ertussen worden gebruikt.

een goed voorbeeld van een NTP-server is ntp.pool.org.dit is een cluster van NTP-servers die veel servers en netwerkapparaten gebruiken om hun klokken te synchroniseren.

NTP gebruikt een concept genaamd “stratum” dat definieert hoeveel NTP een apparaat weghoopt van een auteurende tijdbron. Bijvoorbeeld, een apparaat met stratum 1 is een zeer nauwkeurig apparaat en kan een atoomklok aan het hebben. Een andere NTP-server die deze stratum 1-server gebruikt om zijn eigen tijd te synchroniseren, zou een stratum 2-apparaat zijn omdat het een NTP-hop verder van de bron verwijderd is. Wanneer u meerdere NTP-servers configureert, geeft de client de voorkeur aan de NTP-server met de laagste stratum-waarde.

Cisco-routers en switches kunnen 3 verschillende NTP-modi gebruiken:

• NTP-clientmodus.
• NTP-servermodus.
• NTP symmetrische actieve modus.

de symmetrische actieve modus wordt gebruikt tussen NTP-apparaten om met elkaar te synchroniseren, het wordt gebruikt als een back-upmechanisme wanneer ze de (externe) NTP-server niet kunnen bereiken.

in de rest van deze les zal Ik laten zien hoe NTP te configureren op een Cisco router en switches.

configuratie

dit is de topologie die Ik zal gebruiken:

de router aan de bovenkant wordt “CoreRouter” genoemd en is de rand van mijn netwerk. Het is verbonden met het Internet en zal gebruik maken van een van de NTP-servers van pool.ntp.org om de klok te synchroniseren. Het netwerk heeft ook twee interne schakelaars die gesynchroniseerde klokken vereisen. Beide switches worden NTP clients van de CoreRouter, waardoor de CoreRouter een NTP server wordt.

routerconfiguratie

eerst zullen we de CoreRouter bovenaan configureren. Ik zal gebruiken pool.ntp.org als de externe NTP server voor dit voorbeeld. We moeten ervoor zorgen dat de router hostnamen kan oplossen:

CoreRouter(config)#ip name-server 8.8.8.8

Ik zal Google DNS gebruiken voor dit. Onze volgende stap is het configureren van de NTP-server:

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

dat was makkelijk genoeg, slechts één commando en we zullen onze klok synchroniseren met de publieke server. We kunnen ons werk zo verifiëren:

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

hierboven zien we het show ntp associations commando dat ons vertelt of onze klok gesynchroniseerd is of niet. De ~ voor het IP-adres vertelt ons dat we deze server hebben geconfigureerd, maar we zijn nog niet gesynchroniseerd. U kunt dit zien omdat er geen * Voor het IP-adres staat en het veld” st ” (stratum) momenteel 16 is.

er is nog een commando dat ons meer informatie geeft over de NTP configuratie:

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.

de router vertelt ons dat we niet gesynchroniseerd zijn en dat er geen referentieklok is…we wachten gewoon een paar minuten en nemen een kijkje op deze commando ‘ s opnieuw:

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

een paar minuten later en de output is veranderd. De * voor het IP adres vertelt ons dat we gesynchroniseerd zijn en de stratum is 2…dat betekent dat deze NTP server vrij dicht bij een betrouwbare tijd bron zit. Het veld “poll” vertelt ons dat we zullen proberen om de tijd elke 64 seconden te synchroniseren. Laten we het andere commando controleren dat we net zagen.:

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.

onze klok is gesynchroniseerd en onze eigen stratum is 3, dat is logisch omdat de publieke stratum server heeft een stratum van 2 en we zijn een ” hop ” weg van het.

Cisco-routers hebben twee verschillende klokken, ze hebben een softwareklok en een hardwareklok en ze werken afzonderlijk van elkaar. Zo zie je beide klokken:

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

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

Het Show clock commando toont mij de software klok terwijl het show calendar Commando mij de hardware klok geeft. De twee klokken zijn niet synchroon dus dit is iets wat we moeten repareren, je kunt het zo doen:

CoreRouter#(config)ntp update-calendar

het ntp update-calendar commando zal de hardware klok bijwerken met de tijd van de software klok, hier is het resultaat:

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

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

dat is alles wat ik wilde configureren op de CoreRouter voor nu. We moeten nog twee schakelaars Instellen om hun klokken te synchroniseren.

Switch configuratie

de twee switches zullen worden geconfigureerd om de CoreRouter als NTP-server te gebruiken en Ik zal ze ook configureren om hun klokken met elkaar te synchroniseren. Laten we ze configureren om eerst de CoreRouter te gebruiken:

SW1(config)#ntp server 192.168.123.3

nogmaals het kan een paar minuten duren om te synchroniseren, maar dit is wat u zult zien:

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

de klok van SW1 is gesynchroniseerd en zijn stratum is 4. Dit is logisch omdat het een” hop ” verder weg van zijn NTP-server (CoreRouter). Laten we hetzelfde doen voor SW2:

SW2(config)#ntp server 192.168.123.3

laten we nog een paar minuten geduld hebben en dit is wat we krijgen.:

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 en SW2 gebruiken nu CoreRouter om hun klokken te synchroniseren. Laten we ze ook configureren om elkaar te gebruiken voor synchronisatie. Dit is de symmetrische actieve modus die ik eerder noemde, in principe de twee schakelaars zullen “helpen” elkaar te synchroniseren…dit kan nuttig zijn in het geval de CoreRouter mislukt op een dag:

SW1(config)#ntp peer 192.168.123.2

SW2(config)#ntp peer 192.168.123.1

na een paar minuten wachten zul je zien dat SW1 en SW2 met elkaar gesynchroniseerd zijn:

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

geweldig alles is nu synchroon.

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

zijn we klaar? Nog niet helemaal…er zijn nog een paar dingen die we kunnen doen met NTP. De CoreRouter en de twee switches gebruiken unicast (UDP poort 123) voor synchronisatie, maar je kunt ook multicast of broadcast gebruiken. Laat me je een voorbeeld geven…

Multicast en Broadcast

als je meer dan 20 netwerkapparaten hebt of een router met beperkt systeemgeheugen of CPU-bronnen, zou je kunnen overwegen om NTP broadcast of multicast te gebruiken omdat het minder bronnen vereist. We kunnen multicast of broadcast inschakelen op de interface level.To demonstreer dit Ik zal twee routers toevoegen onder SW1 en SW2 die zichzelf zullen synchroniseren met behulp van multicast of broadcast. Zo ziet het eruit.:

ik configureer SW1 om multicast-adres 239.1.1.1 te gebruiken en SW2 zal NTP-updates verzenden via broadcast: