Cisco Network Time Protocol (NTP)

NTP (Network Time Protocol) wird verwendet, um Netzwerkgeräten die Synchronisierung ihrer Uhren mit einer zentralen Quelluhr zu ermöglichen. Für Netzwerkgeräte wie Router, Switches oder Firewalls ist dies sehr wichtig, da wir sicherstellen möchten, dass Protokollierungsinformationen und Zeitstempel die genaue Uhrzeit und das genaue Datum haben. Wenn Sie jemals Netzwerkprobleme haben oder gehackt werden, möchten Sie sicherstellen, dass Sie genau wissen, was und wann es passiert ist.

Normalerweise läuft ein Router oder Switch im NTP-Client-Modus, was bedeutet, dass er seine Uhr basierend auf der Zeit eines NTP-Servers anpasst. Grundsätzlich beschreibt das NTP-Protokoll den Algorithmus, mit dem die NTP-Clients ihre Uhren mit dem NTP-Server und den zwischen ihnen verwendeten Paketen synchronisieren.

Ein gutes Beispiel für einen NTP-Server ist ntp.pool.org . Dies ist ein Cluster von NTP-Servern, mit denen viele Server und Netzwerkgeräte ihre Uhren synchronisieren.

NTP verwendet ein Konzept namens „Stratum“, das definiert, wie viele NTP-Hops ein Gerät von einer autorisierenden Zeitquelle entfernt ist. Zum Beispiel ist ein Gerät mit Stratum 1 ein sehr genaues Gerät und könnte eine Atomuhr daran befestigt haben. Ein anderer NTP-Server, der diesen Stratum 1-Server verwendet, um seine eigene Zeit zu synchronisieren, wäre ein Stratum 2-Gerät, da es einen NTP-Hop weiter von der Quelle entfernt ist. Wenn Sie mehrere NTP-Server konfigurieren, bevorzugt der Client den NTP-Server mit dem niedrigsten Stratum-Wert.

Cisco Router und Switches können 3 verschiedene NTP-Modi verwenden:

• NTP-Client-Modus.
• NTP-Server-Modus.
• NTP symmetrischer aktiver Modus.

Der symmetrische aktive Modus wird zwischen NTP-Geräten verwendet, um miteinander zu synchronisieren, es wird als Backup-Mechanismus verwendet, wenn sie den (externen) NTP-Server nicht erreichen können.

Im Verlauf dieser Lektion werde ich zeigen, wie NTP auf einem Cisco-Router und Switches konfigurieren.

Konfiguration

Dies ist die Topologie, die ich verwenden werde:

Der Router oben heißt „CoreRouter“ und ist der Rand meines Netzwerks. Es ist mit dem Internet verbunden und verwendet einen der NTP-Server von pool.ntp.org um seine Uhr zu synchronisieren. Das Netzwerk verfügt außerdem über zwei interne Switches, die synchronisierte Uhren erfordern. Beide Switches werden zu NTP-Clients des CoreRouter, wodurch der CoreRouter zu einem NTP-Server wird.

Router-Konfiguration

Zuerst konfigurieren wir den CoreRouter oben. Ich werde verwenden pool.ntp.org als externer NTP-Server für dieses Beispiel. Wir müssen sicherstellen, dass der Router Hostnamen auflösen kann:

CoreRouter(config)#ip name-server 8.8.8.8

Ich werde dafür Google DNS verwenden. Unser nächster Schritt ist die Konfiguration des NTP-Servers:

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

Das war einfach genug, nur ein Befehl und wir werden unsere Uhr mit dem öffentlichen Server synchronisieren. Wir können unsere Arbeit so überprüfen:

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

Oben sehen wir den Befehl show ntp associations, der uns mitteilt, ob unsere Uhr synchronisiert ist oder nicht. Das ~ vor der IP-Adresse sagt uns, dass wir diesen Server konfiguriert haben, aber noch nicht synchronisiert sind. Sie können dies sehen, da vor der IP-Adresse kein * steht und das Feld „st“ (Stratum) derzeit 16 ist.

Es gibt einen weiteren Befehl, der uns weitere Informationen zur NTP-Konfiguration gibt:

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.

Der Router sagt uns, dass wir unsynchronisiert sind und dass es keine Referenzuhr gibt … wir werden nur ein paar Minuten warten und uns diese Befehle erneut ansehen:

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

Ein paar Minuten später und die Ausgabe hat sich geändert. Das * vor der IP-Adresse sagt uns, dass wir synchronisiert haben und die Schicht 2 ist … das bedeutet, dass dieser NTP-Server einer zuverlässigen Zeitquelle ziemlich nahe kommt. Das Feld „Umfrage“ sagt uns, dass wir versuchen werden, die Zeit alle 64 Sekunden zu synchronisieren. Lassen Sie uns den anderen Befehl überprüfen, den wir gerade gesehen haben:

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.

Unsere Uhr wurde synchronisiert und unsere eigene Schicht ist 3, das macht Sinn, da der öffentliche Stratum-Server eine Schicht von 2 hat und wir einen „Sprung“ davon entfernt sind.

Cisco-Router haben zwei verschiedene Uhren, sie haben eine Software-Uhr und eine Hardware-Uhr und sie arbeiten getrennt voneinander. So sehen Sie beide Uhren:

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

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

Der Befehl show clock zeigt mir die Software-Uhr, während der Befehl show calendar mir die Hardware-Uhr gibt. Die beiden Uhren sind nicht synchron, also sollten wir das beheben, Sie können es so machen:

CoreRouter#(config)ntp update-calendar

Der Befehl ntp update-calendar aktualisiert die Hardwareuhr mit der Uhrzeit der Softwareuhr, hier ist das Ergebnis:

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

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

Das ist alles, was ich jetzt auf dem CoreRouter konfigurieren wollte. Wir müssen noch zwei Schalter konfigurieren, um ihre Uhren zu synchronisieren.

Switch-Konfiguration

Die beiden Switches werden so konfiguriert, dass sie den CoreRouter als NTP-Server verwenden, und ich werde sie auch so konfigurieren, dass sie ihre Uhren miteinander synchronisieren. Konfigurieren wir sie so, dass sie zuerst den CoreRouter verwenden:

SW1(config)#ntp server 192.168.123.3

Die Synchronisierung kann erneut einige Minuten dauern, aber Sie werden Folgendes sehen:

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

Die Uhr von SW1 wurde synchronisiert und ihre Schicht ist 4. Dies ist sinnvoll, da es einen „Sprung“ weiter von seinem NTP-Server (CoreRouter) entfernt ist. Machen wir dasselbe für SW2:

SW2(config)#ntp server 192.168.123.3

Lass uns noch ein paar Minuten Geduld haben und das bekommen wir:

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 und SW2 verwenden jetzt CoreRouter, um ihre Uhren zu synchronisieren. Konfigurieren wir sie auch so, dass sie sich gegenseitig für die Synchronisierung verwenden. Dies ist der symmetrische aktive Modus, den ich zuvor erwähnt habe, im Grunde „helfen“ sich die beiden Schalter gegenseitig bei der Synchronisation … dies könnte nützlich sein, falls der CoreRouter eines Tages ausfällt:

SW1(config)#ntp peer 192.168.123.2

SW2(config)#ntp peer 192.168.123.1

Nachdem Sie einige Minuten gewartet haben, sehen Sie, dass SW1 und SW2 miteinander synchronisiert wurden:

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

Großartig alles ist jetzt synchron.

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

Sind wir fertig? Noch nicht ganz … es gibt noch ein paar Dinge, die wir mit NTP tun können. Der CoreRouter und die beiden Switches verwenden Unicast (UDP-Port 123) für die Synchronisation, aber Sie können auch Multicast oder Broadcast verwenden. Lassen Sie mich Ihnen ein Beispiel geben …

Multicast und Broadcast

Wenn Sie mehr als 20 Netzwerkgeräte oder einen Router mit begrenzten Systemspeicher- oder CPU-Ressourcen haben, sollten Sie NTP Broadcast oder Multicast verwenden, da es weniger Ressourcen benötigt. Wir können Multicast oder Broadcast auf der Schnittstelle aktivieren level.To dazu werde ich zwei Router unter SW1 und SW2 hinzufügen, die sich über Multicast oder Broadcast synchronisieren. So sieht es aus:

Ich konfiguriere SW1 für die Verwendung der Multicast-Adresse 239.1.1.1 und SW2 sendet NTP-Updates über Broadcast: