Best Practices für Network Time Protocol

Einleitung

In diesem Dokument werden die Best Practices für das Design des Network Time Protocol beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in diesem Thema verfügen:   

• Network Time Protocol

• Uhrentechnologie und Public Time Server

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

IP-basierte Netzwerke haben sich schnell vom traditionellen Best Effort-Bereitstellungsmodell hin zu einem Modell entwickelt, bei dem Leistung und Zuverlässigkeit quantifiziert und in vielen Fällen durch Service Level Agreements (SLAs) garantiert werden müssen. Der Bedarf an besseren Einblicken in Netzwerkmerkmale hat zu umfangreichen Forschungsanstrengungen geführt, die sich auf wichtige Metriken und Messfunktionen zur Charakterisierung des Netzwerkverhaltens konzentrieren. Die Grundlage vieler metrischer Methoden ist die Messung der Zeit.

Die Synchronisierung der Netzwerkzeiten ist im Rahmen einer modernen Leistungsanalyse unerlässlich. Basierend auf den Geschäftsmodellen und den bereitgestellten Services wird die Charakterisierung der Netzwerkleistung als wichtiges Differenzierungsmerkmal im Wettbewerb betrachtet. In diesen Fällen entstehen hohe Kosten, wenn Sie Netzwerkmanagementsysteme und direkte technische Ressourcen bereitstellen, um die erfassten Leistungsdaten zu analysieren. Wenn jedoch dem oft übersehenen Prinzip der Zeitsynchronisierung keine angemessene Beachtung geschenkt wird, sind diese Bemühungen unwirksam.

In diesem Dokument wird eine hypothetische Prozessdefinition für das Netzwerkmanagement-Funktionsmanagement für das Network Time Protocol (NTP) beschrieben. Sie können diesen Artikel als hypothetisches Verfahren und als Informationsbeispiel verwenden. Dies kann von einer Organisation angepasst werden, um interne Ziele zu erreichen.

Die in diesem Dokument enthaltenen Informationen sind in mehrere Abschnitte gegliedert:

• Der Abschnitt Terminologie enthält allgemeine Begriffsdefinitionen zur Zeitsynchronisierung.
• Der Abschnitt Overview (Übersicht) enthält Hintergrundinformationen zur Netzwerkelement-Hardware in Bezug auf die Systemzeit, einen technologischen Überblick über NTP und wichtige Designaspekte für die NTP-Architektur.
• Der Abschnitt Beispiel für die NTP-Bereitstellung enthält Beispiele für die NTP-Bereitstellung mit Beispielkonfigurationen für WAN-, Campus-Netzwerke mit hoher und Campus-Zeitverteilungsnetzwerke mit niedriger Schicht.
• Der Abschnitt Prozessdefinitionen bietet einen Überblick über die Prozessdefinitionen für die NTP-Verwaltung. Die Prozessdetails werden anhand von Zielen, Leistungsindikatoren, Inputs, Outputs und einzelnen Aufgaben beschrieben.
• Der Abschnitt Aufgabendefinitionen enthält detaillierte Definitionen von Prozessaufgaben. Jede Aufgabe wird in Form von Zielen, Aufgabeneingaben, Aufgabenausgaben, erforderlichen Ressourcen zur Ausführung der Aufgabe und erforderlichen Fertigkeiten für die Aufgabenimplementierung beschrieben.
• Im Abschnitt Datenidentifizierung wird die Datenidentifizierung für NTP beschrieben. Bei der Datenidentifizierung wird die Quelle der Informationen berücksichtigt. Informationen können beispielsweise in der Simple Network Management Protocol (SNMP) Management Information Base (MIB), in von Syslog generierten Protokolldateien oder in internen Datenstrukturen enthalten sein, auf die nur über die Befehlszeilenschnittstelle (CLI) zugegriffen werden kann.
• Im Abschnitt Datenerfassung wird die Erfassung der NTP-Daten beschrieben. Die Erhebung der Daten steht in engem Zusammenhang mit dem Ort der Daten. SNMP MIB-Daten werden beispielsweise durch verschiedene Mechanismen wie Traps, Remote Monitoring (RMON)-Alarme und -Ereignisse oder Polling erfasst. Daten, die von internen Datenstrukturen verwaltet werden, werden durch automatische Skripte erfasst oder wenn sich ein Benutzer manuell beim System anmeldet, um den CLI-Befehl auszugeben und die Ausgabe aufzuzeichnen.
• Im Abschnitt Datenpräsentation finden Sie Beispiele im Berichtsformat, wie die Daten dargestellt werden können.

Terminologie

• Genauigkeit - Die Nähe des absoluten Werts des Takts zum Offset von Null.

• Accurate (Genauigkeit) - Wenn ein Uhren-Offset zu einem bestimmten Zeitpunkt Null ist.

• Drift (Drift) - Die Messung in der Variation von Skew oder die zweite Ableitung des Taktversatzes in Bezug auf die Zeit.

• Gemeinsame Auflösung - Wenn Uhren verglichen werden, ist dies die Summe der Auflösungen von C1 und C2. Die gemeinsame Auflösung gibt dann eine konservative Untergrenze der Genauigkeit von Zeitintervallen an, die durch Zeitstempel berechnet werden, die von einer Uhr erzeugt werden, die von den Zeitstempeln der anderen Uhr subtrahiert wird.

• Node (Knoten): Bezeichnet eine Instanziierung des NTP-Protokolls auf einem lokalen Prozessor. Ein Knoten kann auch als Gerät bezeichnet werden.

• Offset (Offset) - Die Differenz zwischen der von einer Uhr gemeldeten Zeit und der wahren Zeit, die von der Universellen koordinierten Zeit (UTC, Coordinated Universal Time) definiert wird. Wenn die Uhr eine Zeit Tc meldet und die wahre Zeit Tt ist, dann ist der Taktversatz Tc - Tt.

• Peer - Bezieht sich auf eine Instanziierung des NTP-Protokolls auf einem Remote-Prozessor, der über einen Netzwerkpfad vom lokalen Knoten verbunden ist.

• Relativer Offset - Der Begriff "wahre Zeit" wird durch die Zeit ersetzt, die durch den Takt C1 gemeldet wird, wenn zwei Uhren, C1 und C2, verglichen werden. Beispielsweise ist der Versatz des Taktes C2 relativ zu C1 zu einem bestimmten Zeitpunkt Tc2 - Tc1, die momentane Zeitdifferenz, die von C2 und C1 gemeldet wird.

• Resolution (Auflösung): Die kleinste Einheit, um die eine Uhrzeit aktualisiert wird. Die Auflösung wird in Sekunden angegeben. Die Auflösung ist jedoch relativ zur gemeldeten Uhrzeit und nicht zur wahren Zeit. Eine Auflösung von 10 Millisekunden bedeutet beispielsweise, dass die Uhr ihren Zeitbegriff in Schritten von 0,01 Sekunden aktualisiert, und nicht, dass dies der tatsächliche Zeitraum zwischen den Updates ist.

  Hinweis: Uhren können sehr feine Auflösungen haben und immer noch ungenau sein.

• Skew (Verzerrung) - Eine Taktfrequenzdifferenz oder die erste Ableitung ihres Offsets in Bezug auf die Zeit.

• Synchronisieren (Synchronize) - Wenn zwei Uhren genau zueinander sind (der relative Offset ist Null), werden sie synchronisiert. Uhren können synchronisiert werden und immer noch ungenau in Bezug darauf, wie gut sie wahre Zeit erzählen.

Überblick

Geräteübersicht

Das Herzstück des Zeitdienstes ist die Systemuhr. Die Systemuhr läuft ab dem Zeitpunkt, an dem das System gestartet wird, und verfolgt das aktuelle Datum und die aktuelle Uhrzeit. Die Systemuhr kann aus einer Vielzahl von Quellen eingestellt werden und kann wiederum dazu verwendet werden, die aktuelle Zeit über verschiedene Mechanismen auf andere Systeme zu verteilen. Einige Router enthalten ein batteriebetriebenes Kalendersystem, das Datum und Uhrzeit bei Systemneustarts und Stromausfällen verfolgt. Dieses Kalendersystem wird immer verwendet, um die Systemuhr zu initialisieren, wenn das System neu gestartet wird. Sie kann auch als maßgebliche Zeitquelle angesehen und über NTP umverteilt werden, wenn keine andere Quelle verfügbar ist. Wenn NTP aktiviert ist, wird der Kalender darüber hinaus regelmäßig vom NTP aktualisiert. Dadurch wird die inhärente Verschiebung der Kalenderzeit ausgeglichen. Wenn ein Router mit einem Systemkalender initialisiert wird, wird die Systemuhr anhand der Zeit im internen batteriebetriebenen Kalender eingestellt. Bei Modellen ohne Kalender wird die Systemuhr auf eine vorgegebene Zeitkonstante eingestellt. Die Systemuhr kann aus den als Nächstes aufgeführten Quellen eingestellt werden.

• NTP

• Simple Network Time Protocol (SNTP)

• Virtual Integrated Network Service (VINES) Time Service

• Manuelle Konfiguration

Einige einfache Cisco Geräte unterstützen nur SNTP. SNTP ist eine vereinfachte, nur auf Clients beschränkte Version von NTP. SNTP kann nur die Zeit von NTP-Servern empfangen und nicht verwendet werden, um Zeitdienste für andere Systeme bereitzustellen. SNTP liefert normalerweise eine Zeit innerhalb von 100 Millisekunden nach der genauen Zeit. Darüber hinaus authentifiziert SNTP keinen Datenverkehr. Sie können jedoch erweiterte Zugriffslisten konfigurieren, um einen gewissen Schutz zu gewährleisten. Ein SNTP-Client ist anfälliger für nicht konforme Server als ein NTP-Client und darf nur in Situationen verwendet werden, in denen keine starke Authentifizierung erforderlich ist.

Die Systemuhr zeigt die Zeit für die als Nächstes aufgeführten Dienste an.

• NTP

• VINES-Zeitdienst

• Benutzer zeigt Befehle

• Protokollieren und Debuggen von Meldungen

Die Systemuhr verfolgt intern die Zeit basierend auf UTC, auch bekannt als Greenwich Mean Time (GMT). Sie können Informationen über die lokale Zeitzone und die Sommerzeit so konfigurieren, dass die Zeit in Bezug auf die lokale Zeitzone korrekt angezeigt wird. Die Systemuhr verfolgt, ob die Zeit maßgebend ist oder nicht. Ist sie nicht autoritär, kann die Zeit nur für Anzeigezwecke zur Verfügung stehen und kann nicht umverteilt werden.

NTP - Übersicht

Das NTP wurde zur Synchronisierung der Uhrzeit in einem Netzwerk von Systemen entwickelt. Das NTP wird über das User Datagram Protocol (UDP) ausgeführt, wobei Port 123 sowohl als Quelle als auch als Ziel fungiert, das wiederum über IP ausgeführt wird. NTP Version 3 RFC 1305 wird zur Synchronisierung der Zeiterfassung für eine Reihe von verteilten Zeitservern und Clients verwendet. Eine Gruppe von Knoten in einem Netzwerk wird mit NTP identifiziert und konfiguriert, und die Knoten bilden ein Synchronisierungs-Subnetz, das manchmal als Overlay-Netzwerk bezeichnet wird. Es können zwar mehrere primäre Server vorhanden sein, ein Auswahlprotokoll ist jedoch nicht erforderlich.

Ein NTP-Netzwerk erhält seine Uhrzeit normalerweise von einer zuverlässigen Zeitquelle, z. B. einer mit einem Zeitserver verbundenen Funkuhr oder Atomuhr. NTP verteilt diese Zeit dann über das Netzwerk. Ein NTP-Client führt über sein Abfrageintervall (von 64 auf 1024 Sekunden) eine Transaktion mit seinem Server durch, die sich im Laufe der Zeit dynamisch in Abhängigkeit von den Netzwerkbedingungen zwischen dem NTP-Server und dem Client ändert. Die andere Situation tritt auf, wenn der Router mit einem fehlerhaften NTP-Server kommuniziert (z. B. einem NTP-Server mit großer Dispersion). Der Router erhöht auch das Abfrageintervall. Es ist nicht mehr als eine NTP-Transaktion pro Minute erforderlich, um zwei Systeme zu synchronisieren.

Das NTP nutzt das Schichtenkonzept, um zu beschreiben, wie viele NTP-Hops ein Rechner von einer maßgeblichen Zeitquelle entfernt ist. Beispielsweise ist ein Schicht-1-Zeitserver direkt mit einer Funk- oder Atomuhr verbunden. Anschließend wird die Uhrzeit über NTP an einen Schicht-2-Zeitserver gesendet usw. Ein Computer, der das NTP ausführt, wählt automatisch den Computer mit der niedrigsten Schicht-Nummer aus, für die die Kommunikation mit dem NTP als Zeitquelle konfiguriert ist. Mit dieser Strategie wird auf effektive Weise ein sich selbst organisierender Tree aus NTP-Routern erstellt. NTP schneidet bei den nicht deterministischen Pfadlängen von paketvermittelten Netzwerken gut ab, da es robuste Schätzungen der nächsten drei Schlüsselvariablen in der Beziehung zwischen einem Client und einem Zeitserver erstellt.

• Netzwerkverzögerung

• Zeitliche Verteilung des Paketaustauschs - Ein Maß für den maximalen Uhrfehler zwischen den beiden Hosts.

• Uhren-Offset - Die Korrektur, die auf eine Client-Uhr angewendet wird, um diese zu synchronisieren.

Die Uhrensynchronisierung erfolgt auf der Ebene von 10 Millisekunden über WANs (2000 km) für große Entfernungen und auf der Ebene von 1 Millisekunde für LANs.

Es gibt zwei Möglichkeiten, wie das NTP nicht mit einem Computer synchronisiert werden kann, dessen Uhrzeit ungenau ist. Erstens führt das NTP keine Synchronisierung mit einem System durch, das nicht selbst synchronisiert wurde. Zweitens vergleicht das NTP die von mehreren Systemen gemeldete Zeit und führt keine Synchronisierung mit Systemen durch, deren Uhrzeit sich erheblich von der der anderen Systeme unterscheidet, selbst wenn deren Schicht geringer ist.

Die Kommunikation zwischen Computern, auf denen NTP ausgeführt wird (Verknüpfungen), wird in der Regel statisch konfiguriert. Jeder Rechner erhält die IP-Adresse aller Rechner, mit denen er Zuordnungen bilden muss. Eine genaue Zeiterfassung wird durch NTP-Nachrichten ermöglicht, die zwischen zwei Rechnern mit einer Zuordnung ausgetauscht werden. In einer LAN-Umgebung kann das NTP jedoch so konfiguriert werden, dass es stattdessen IP-Broadcast-Nachrichten verwendet. Diese Alternative verringert den Konfigurationsaufwand, da jeder Computer so konfiguriert werden kann, dass er Broadcast-Nachrichten sendet oder empfängt. Die Genauigkeit der Zeiterfassung wird jedoch geringfügig reduziert, da der Informationsfluss nur in eine Richtung erfolgt.

Die auf einem Computer gespeicherte Zeit ist eine wichtige Ressource, und es wird dringend empfohlen, die Sicherheitsfunktionen von NTP zu verwenden, um versehentliche oder böswillige Einstellungen falscher Zeit zu vermeiden. Die beiden verfügbaren Sicherheitsfunktionen sind ein Zugriffslisten-basiertes Beschränkungsschema und ein verschlüsselter Authentifizierungsmechanismus.

Die NTP-Implementierung von Cisco unterstützt den Schicht-1-Service bestimmter Cisco IOS®-Softwareversionen. Wenn ein Release den Befehl ntp refclock unterstützt, ist es möglich, eine Funk- oder Atomuhr anzuschließen. Bestimmte Versionen von Cisco IOS unterstützen entweder das Trimble Palisade NTP Synchronization Kit (nur Cisco Router der Serie 7200) oder das Telecom Solutions Global Positioning System (GPS). Wenn das Netzwerk die öffentlichen Zeitserver im Internet verwendet und das Netzwerk vom Internet isoliert ist, ermöglicht die Implementierung von NTP durch Cisco die Konfiguration eines Systems, sodass es wie über NTP synchronisiert agiert, obwohl es die Zeit tatsächlich auf andere Weise bestimmt hat. Andere Systeme werden dann über NTP mit diesem System synchronisiert.

NTP-Designkriterien

Jeder Client im Synchronisierungs-Subnetz, der auch ein Server für Clients höherer Schichten sein kann, wählt einen der verfügbaren Server für die Synchronisierung aus. Dieser Server gehört in der Regel zu den Servern der untersten Schicht, auf die er Zugriff hat. Dies ist jedoch nicht immer eine optimale Konfiguration, da das NTP ebenfalls unter der Prämisse betrieben wird, dass jede Serverzeit mit einem gewissen Maß an Misstrauen betrachtet werden muss. NTP bevorzugt den Zugriff auf mehrere Quellen einer kürzeren Schicht (mindestens drei), da es dann einen Vereinbarungsalgorithmus anwenden kann, um Wahnsinn von einer dieser Quellen zu erkennen. Wenn alle Server übereinstimmen, wählt das NTP in der Regel den besten Server in Bezug auf die niedrigste Schicht, die nächstgelegene Schicht (in Bezug auf die Netzwerkverzögerung) und die angegebene Genauigkeit aus. Dies bedeutet, dass zwar angestrebt werden muss, jedem Client drei oder mehr Quellen für kürzere Schichten zur Verfügung zu stellen, dass jedoch einige von ihnen nur Backup-Services bereitstellen können und in Bezug auf Netzwerkverzögerungen und Schichten von geringerer Qualität sein können. Beispielsweise kann ein Peer derselben Schicht, der Zeit von Quellen einer niedrigeren Schicht erhält, auf die der lokale Server nicht direkt zugreift, ebenfalls einen guten Backup-Service bieten.

Das NTP bevorzugt in der Regel Server mit niedrigeren Schichten gegenüber Servern mit höheren Schichten, es sei denn, die Serverzeit mit niedrigeren Schichten unterscheidet sich erheblich. Der Algorithmus ist in der Lage, zu erkennen, wenn eine Zeitquelle wahrscheinlich extrem ungenau oder irrsinnig ist, und um Synchronisation in diesen Fällen zu verhindern, auch wenn die ungenaue Uhr auf einer niedrigeren Schicht Ebene ist. Und es kann niemals ein Gerät mit einem anderen Server synchronisieren, der nicht selbst synchronisiert ist.

Um zu erklären, ob der Server zuverlässig ist, muss er viele Plausibilitätsprüfungen bestehen, z. B.:

• Die Implementierungen müssen Zeitüberschreitungen für die Vernunft enthalten, die Trap-Übertragungen verhindern, wenn das Überwachungsprogramm diese Informationen nach einem längeren Intervall nicht erneuert.

• Zusätzliche Plausibilitätsprüfungen sind für die Authentifizierung, Bereichsgrenzen und zur Vermeidung der Verwendung sehr alter Daten enthalten.

• Es wurden Prüfungen hinzugefügt, um zu warnen, dass der Oszillator zu lange gegangen ist, ohne dass er von einer Referenzquelle aktualisiert wurde.

• Die Variablen peer.valid und sys.hold wurden hinzugefügt, um Instabilitäten zu vermeiden, wenn sich die Referenzquelle aufgrund großer dispersiver Verzögerungen bei starken Netzwerküberlastungen schnell ändert. Die Bits "peer.config", "peer.Authenticable" und "peer.Authenticable" wurden hinzugefügt, um spezielle Funktionen zu steuern und die Konfiguration zu vereinfachen.

Wenn mindestens eine dieser Prüfungen fehlschlägt, erklärt der Router dies für unzutreffend.

Zuordnungsmodi

In den nächsten Abschnitten werden die Zuordnungsmodi beschrieben, die die NTP-Server für die Zuordnung untereinander verwenden.

• Client/Server

• Symmetrisch Aktiv/Passiv

• Senden

Client/Server-Modus

Abhängige Clients und Server arbeiten normalerweise im Client/Server-Modus, in dem ein Client oder ein abhängiger Server mit einem Gruppenmitglied synchronisiert werden kann, jedoch kein Gruppenmitglied mit dem Client oder dem abhängigen Server synchronisiert werden kann. Dies bietet Schutz vor Fehlfunktionen oder Protokollangriffen.

Der Client-Server-Modus ist die am häufigsten verwendete Internetkonfiguration. Es arbeitet im klassischen RPC-Paradigma (Remote Procedure Call) mit Stateless Servern. In diesem Modus sendet ein Client eine Anfrage an den Server und erwartet zu einem späteren Zeitpunkt eine Antwort. In einigen Kontexten wird dies als Abfragevorgang beschrieben, indem der Client die Zeit- und Authentifizierungsdaten vom Server abfragt. Ein Client wird im Clientmodus mit dem Serverbefehl und dem angegebenen DNS-Namen (Domain Name Server) oder der angegebenen Adresse konfiguriert. Für den Server ist keine vorherige Konfiguration erforderlich.

In einem allgemeinen Client/Server-Modell sendet ein Client eine NTP-Nachricht an einen oder mehrere Server und verarbeitet die Antworten, wie sie empfangen werden. Der Server tauscht Adressen und Ports aus, überschreibt bestimmte Felder in der Nachricht, berechnet die Prüfsumme neu und sendet die Nachricht sofort zurück. Mithilfe der in der NTP-Nachricht enthaltenen Informationen kann der Client die Serverzeit in Bezug auf die lokale Zeit bestimmen und dann die lokale Uhr nach Bedarf anpassen. Darüber hinaus enthält die Nachricht Informationen zur Berechnung der erwarteten Genauigkeit und Zuverlässigkeit der Zeiterfassung sowie zur Auswahl des besten Servers.

Server, die eine Synchronisierung mit einer großen Anzahl von Clients ermöglichen, arbeiten normalerweise als Gruppe von drei oder mehr gegenseitig redundanten Servern und arbeiten jeweils mit drei oder mehr Schicht-1- oder Schicht-2-Servern im Client/Server-Modus sowie mit allen anderen Mitgliedern der Gruppe im symmetrischen Modus. Dies bietet Schutz vor Fehlfunktionen, bei denen ein oder mehrere Server ausfallen oder eine falsche Zeit liefern. Die NTP-Algorithmen sind so konzipiert, dass sie vor Angriffen schützen, wenn ein Bruchteil der konfigurierten Synchronisierungsquellen versehentlich oder vorsätzlich eine falsche Zeit liefert. In diesen Fällen wird ein spezielles Abstimmungsverfahren angewandt, um falsche Quellen zu identifizieren und ihre Daten zu verwerfen. Aus Gründen der Zuverlässigkeit können ausgewählte Hosts mit externen Uhren ausgestattet und für Backups bei Ausfall des primären und/oder sekundären Servers bzw. der Kommunikationswege zwischen diesen verwendet werden.

Die Konfiguration einer Zuordnung im Clientmodus wird normalerweise durch eine Serverdeklaration in der Konfigurationsdatei angegeben und gibt an, dass Sie Zeit vom Remoteserver abrufen möchten, dass Sie jedoch keine Zeit für den Remoteserver angeben möchten.

Symmetrischer Aktiv/Passiv-Modus

Der symmetrische Aktiv/Passiv-Modus ist für Konfigurationen vorgesehen, bei denen eine Gruppe von Peers auf einer niedrigen Schicht als gegenseitige Backups fungiert. Jeder Peer arbeitet mit einer oder mehreren primären Referenzquellen, z. B. einer Funkuhr oder einer Untergruppe zuverlässiger sekundärer Server. Wenn einer der Peers alle Referenzquellen verliert oder einfach den Betrieb beendet, werden die anderen Peers automatisch neu konfiguriert, sodass Zeitwerte von den aktuellen Peers zu allen anderen in der Warteschlange fließen können. In einigen Kontexten wird dies als Push-Pull-Vorgang beschrieben, indem der Peer entweder die Zeit und die Werte basierend auf der jeweiligen Konfiguration zieht oder verschiebt.

Die Konfiguration einer Zuordnung im symmetrisch-aktiven Modus, die üblicherweise durch eine Peer-Deklaration in der Konfigurationsdatei angegeben wird, weist den Remote-Server darauf hin, dass man Zeit vom Remote-Server beziehen möchte und dass man auch bereit ist, dem Remote-Server bei Bedarf Zeit zuzuführen. Dieser Modus eignet sich für Konfigurationen mit mehreren redundanten Zeitservern, die über verschiedene Netzwerkpfade miteinander verbunden sind. Dies ist derzeit bei den meisten Schicht-1- und Schicht-2-Servern im Internet der Fall.

Symmetrische Modi werden am häufigsten zwischen zwei oder mehr Servern verwendet, die als gegenseitig redundante Gruppe arbeiten. In diesen Modi legen die Server in den Gruppenmitgliedern die Synchronisierungspfade so fest, dass eine maximale Leistung erzielt wird, basierend auf dem Netzwerk-Jitter und der Weiterleitungsverzögerung. Wenn eines oder mehrere der Gruppenmitglieder ausfallen, werden die verbleibenden Mitglieder automatisch neu konfiguriert.

Ein Peer wird mit dem Befehl peer im symmetrischen Aktiv-Modus konfiguriert, wenn der DNS-Name oder die Adresse des anderen Peers angegeben wird. Der andere Peer wird auf diese Weise ebenfalls im symmetrischen aktiven Modus konfiguriert.

Hinweis: Wenn der andere Peer nicht speziell auf diese Weise konfiguriert ist, wird bei Eintreffen einer symmetrischen aktiven Nachricht eine symmetrische passive Zuordnung aktiviert. Da ein Eindringling einen symmetrischen aktiven Peer imitieren und falsche Zeitwerte einschleusen kann, muss der symmetrische Modus immer authentifiziert werden.

Broadcast- und/oder Multicast-Modus

Wenn die Anforderungen an die Genauigkeit und Zuverlässigkeit eher gering sind, können die Clients für die Verwendung des Broadcast- und/oder Multicast-Modus konfiguriert werden. Normalerweise werden diese Modi nicht von Servern mit abhängigen Clients verwendet. Der Vorteil besteht darin, dass die Clients nicht für einen bestimmten Server konfiguriert werden müssen. Dies ermöglicht es allen Clients, dieselbe Konfigurationsdatei zu verwenden. Für den Broadcast-Modus ist ein Broadcast-Server im gleichen Subnetz erforderlich. Da Broadcast-Nachrichten nicht von Routern weitergeleitet werden, werden nur Broadcast-Server im gleichen Subnetz verwendet.

Der Broadcast-Modus ist für Konfigurationen vorgesehen, die einen oder mehrere Server und eine potenziell große Client-Population betreffen. Ein Broadcast-Server wird mit dem Broadcast-Befehl und einer lokalen Subnetzadresse konfiguriert. Ein Broadcast-Client wird mit dem Befehl Broadcast Client konfiguriert, der es dem Broadcast-Client ermöglicht, auf Broadcast-Nachrichten zu reagieren, die auf einer beliebigen Schnittstelle empfangen werden. Da ein Eindringling einen Broadcast-Server imitieren und falsche Zeitwerte einschleusen kann, muss dieser Modus immer authentifiziert werden.

NTP-Leap-Sekunde festlegen

Sie können den ntp-Sprung {add | delete}-Befehl, um eine Schaltsekunde einzufügen. Es gibt Optionen zum Hinzufügen oder Löschen von Schaltsekunden. Es gibt zwei Einschränkungen für diesen Vorgang:

• Die Uhr muss im Synchronisierungsstatus sein.

• Der Befehl wird nur innerhalb des Monats akzeptiert, bevor der Sprung erfolgen soll. Es kann keinen Sprung setzen, wenn die aktuelle Zeit vor 1 Monat nach dem Auftreten des Sprungs liegt.

Nachdem Sie sie gesetzt haben, wird die Schaltsekunde zur letzten Sekunde hinzugefügt oder gelöscht, wie hier gezeigt:

NTP leap second added :
Show clock given continuously
vl-7500-6#show clock
23:59:58.123 UTC Sun Dec 31 2006
vl-7500-6#show clock
23:59:58.619 UTC Sun Dec 31 2006
vl-7500-6#show clock
23:59:59.123 UTC Sun Dec 31 2006
vl-7500-6#show clock
23:59:59.627 UTC Sun Dec 31 2006
<< 59th second occurring twice
vl-7500-6#show clock
23:59:59.131 UTC Sun Dec 31 2006    
vl-7500-6#show clock
23:59:59.627 UTC Sun Dec 31 2006
vl-7500-6#show clock
00:00:00.127 UTC Mon Jan 1 2007
vl-7500-6#show clock
00:00:00.623 UTC Mon Jan 1 2007

NTP-Architektur

Diese drei Strukturen stehen für die NTP-Architektur zur Verfügung:

• Flache Peer-Struktur

• Hierarchische Struktur

• Sternstruktur

In einer flachen Peer-Struktur bilden alle Router eine Peer-Beziehung zueinander, wobei einige geografisch unabhängige Router so konfiguriert sind, dass sie auf externe Systeme verweisen. Die Konvergenzzeit verlängert sich mit jedem neuen Mitglied des NTP-Netzes.

In einer hierarchischen Struktur wird die Routing-Hierarchie für die NTP-Hierarchie kopiert. Core-Router haben eine Client/Server-Beziehung zu externen Zeitquellen, die internen Zeitserver haben eine Client/Server-Beziehung zu den Core-Routern, die internen Benutzer- (Nicht-Zeitserver)-Router haben eine Client/Server-Beziehung zu den internen Zeitservern und so weiter in der Struktur. Diese Beziehungen werden als Hierarchieebenen bezeichnet. Eine hierarchische Struktur ist das bevorzugte Verfahren, da sie Konsistenz, Stabilität und Skalierbarkeit bietet.

Eine skalierbare NTP-Architektur weist eine hierarchische Struktur auf, wie im nächsten Diagramm dargestellt.

Skalierbare NTP-Architektur

In einer Sternstruktur haben alle Router eine Client/Server-Beziehung zu einigen wenigen Zeitservern im Kern. Die dedizierten Zeitserver sind das Zentrum des Sterns und sind in der Regel mit externen Zeitquellen oder einem eigenen GPS-Empfänger synchronisierte UNIX-Systeme.

Uhrentechnologie und Public Time Server

Das Internet-NTP-Subnetz umfasst derzeit über 50 öffentliche primäre Server, die über Funk, Satellit oder Modem direkt mit UTC synchronisiert werden. Normalerweise werden Client-Workstations und Server mit einer relativ kleinen Anzahl von Clients nicht mit primären Servern synchronisiert. Etwa 100 öffentliche sekundäre Server werden mit den primären Servern synchronisiert und ermöglichen die Synchronisierung von insgesamt mehr als 100.000 Clients und Servern im Internet. Die Listen der öffentlichen NTP-Zeitserver werden regelmäßig aktualisiert. Darüber hinaus gibt es zahlreiche private primäre und sekundäre Server, die normalerweise nicht öffentlich zugänglich sind.

Hinweis: PIX und ASA können nicht als NTP-Server, sondern als NTP-Client konfiguriert werden.

In bestimmten Fällen, in denen im privaten Unternehmen hochgenaue Zeitdienste erforderlich sind, z. B. unidirektionale Metriken für VoIP-Messungen, können Netzwerkdesigner private externe Zeitquellen bereitstellen. Das nächste Diagramm zeigt eine vergleichende Grafik der relativen Genauigkeit der aktuellen Technologien.

Vergleichsdiagramm

Bis vor kurzem wurde die Verwendung externer Zeitquellen in Unternehmensnetzwerken aufgrund der hohen Kosten für hochwertige externe Zeitquellen nicht weit verbreitet. Da jedoch die QoS-Anforderungen (Quality of Service) steigen und die Kosten für die Zeittechnologie weiter sinken, sind externe Zeitquellen für Unternehmensnetzwerke eine gangbare Option.

Beispiele für NTP-Bereitstellungen

WAN-Zeitverteilungsnetzwerk

Im nächsten Diagramm bezieht ein autonomes System (AS) eines Unternehmens Zeitinformationen von drei öffentlichen Zeitservern. Das Unternehmens-AS wird als Zeitserver für Area 0 und Area 1 angezeigt. In diesem Beispiel beschreibt die NTP-Hierarchie die OSPF-Hierarchie (Open Shortest Path First). OSPF ist jedoch keine Voraussetzung für NTP. Es wird nur als anschauliches Beispiel verwendet. NTP kann entlang anderer logischer, hierarchischer Grenzen bereitgestellt werden, z. B. einer EIGRP-Hierarchie (Enhanced Interior Gateway Routing Protocol) oder der standardmäßigen Core-/Distribution-/Access-Hierarchie.

WAN-Zeitverteilungsnetzwerk

Dieses Beispiel ist die Cisco IOS-Konfiguration für Gerät A0-R1, wie im vorherigen Diagramm gezeigt.

clock timezone CST -5
clock summer-time CDT recurring


!--- This router has a hardware calendar. 
!--- To configure a system as an 
!--- authoritative time source for a network 
!--- based on its hardware clock (calendar), 
!--- use the clock calendar-valid global 
!--- configuration command. Notice later that 
!--- NTP can be allowed to update the calendar 
!--- and Cisco IOS can be configured to be an 
!--- NTP master clock source. 
!--- Cisco IOS can then obtain its clock from 
!--- the hardware calendar.


clock calendar-valid


!--- This allows NTP to update the hardware 
!--- calendar chip.


ntp update-calendar


!--- Configures the Cisco IOS software as an 
!--- NTP master clock to which peers synchronize 
!--- themselves when an external NTP source is 
!--- not available. Cisco IOS can obtain the 
!--- clock from the hardware calendar based on 
!--- the previous line. This line can keep the 
!--- whole network in Sync even if Router1 loses 
!--- its signal from the Internet. Assume, for 
!--- this example, that the Internet time servers 
!--- are stratum 2.


ntp master 3


!--- When the system sends an NTP packet, the 
!--- source IP address is normally set to the 
!--- address of the interface through which the 
!--- NTP packet is sent. 
!--- Change this to use loopback0.


ntp source Loopback0


!--- Enables NTP authentication.


ntp authenticate
ntp authentication-key 1234 md5 104D000A0618 7
ntp trusted-key 1234


!--- Configures the access control groups for 
!--- the public servers and peers for additional 
!--- security.


access-list 5 permit <I-TS-1>
access-list 5 permit <I-TS-2>
access-list 5 permit <I-TS-3>
access-list 5 permit <A0-R2>
access-list 5 permit <A0-R3>
access-list 5 deny any


!--- Configures the access control groups for the 
!--- clients to this node for additional security.


access-list 6 permit <A1-R1>
access-list 6 permit <A1-R2>
access-list 6 permit <A1-R3>
access-list 6 deny any


!--- Restricts the IP addresses for the peers 
!--- and clients.

 
ntp access-group peer 5
ntp access-group serve-only 6


!--- Fault tolerant configuration polling for 3 NTP 
!--- public servers, peering with 2 local servers.


ntp server <I-TS-1>
ntp server <I-TS-2>
ntp server <I-TS-3>
ntp peer <A0-R2> 
ntp peer <A0-R3>

Campus-Zeitverteilungsnetzwerk mit hoher Schicht

Im vorherigen Abschnitt wurde ein WAN-Zeitverteilungsnetzwerk beschrieben. In diesem Abschnitt wird die Zeitverteilung auf einem Campus-Netzwerk mit hoher Schicht in der Hierarchie einen Schritt nach unten verschoben.

Der Hauptunterschied bei der Zeitverteilung in einem Campus-Netzwerk mit hoher Schicht besteht in der möglichen Verwendung des Broadcast-Zuordnungsmodus. Wie bereits beschrieben, vereinfacht der Broadcast-Zuordnungsmodus die Konfigurationen für die LANs, verringert jedoch die Genauigkeit der Zeitberechnungen. Daher ist der Ausgleich der Wartungskosten gegen die Genauigkeit der Leistungsmessungen zu berücksichtigen.

Campus-Zeitverteilungsnetzwerk mit hoher Schicht

Das im vorherigen Diagramm dargestellte Hochschicht-Campus-Netzwerk basiert auf dem Cisco Campus-Standarddesign und umfasst drei Komponenten. Der Campus-Core besteht aus zwei Layer-3-Geräten mit der Bezeichnung CB-1 und CB-2. Die Serverkomponente befindet sich im unteren Bereich der Abbildung und verfügt über zwei Layer-3-Router mit der Bezeichnung SD-1 und SD-2. Die anderen Geräte im Serverblock sind Layer-2-Geräte. Oben links befindet sich ein Standardzugriffsblock mit zwei Layer-3-Verteilungsgeräten mit der Bezeichnung dl-1 und dl-2. Die übrigen Geräte sind Layer-2-Switches. In diesem Client-Zugriffsblock wird die Zeit mit der Broadcast-Option verteilt. Oben rechts befindet sich ein weiterer Standardzugriffsblock, der eine Client/Server-Zeitverteilungskonfiguration verwendet.

Die Campus-Backbone-Geräte werden in einem Client/Server-Modell mit den Area-Time-Servern synchronisiert.

Dies ist die Konfiguration für die Layer-3-Verteilungsgeräte von dl-1:

!--- In this case, dl-1 can be a broadcast server 
!--- for the Layer 2 LAN.


internet Ethernet0
ntp broadcast

clock timezone CST -5
clock summer-time CDT recurring


!--- When the system sends an NTP packet, the 
!--- source IP address is normally set to the 
!--- address of the interface through which the 
!--- NTP packet is sent. 
!--- Change this to use loopback0.


ntp source Loopback0


!--- Enables NTP authentication.


ntp authenticate
ntp authentication-key 1234 md5 104D000A0618 7
ntp trusted-key 1234


!--- Configures the access control groups for 
!--- the public servers and peers for 
!--- additional security.


access-list 5 permit <CB-1>
access-list 5 permit <CB-2>
access-list 5 permit <dl-2>
access-list 5 deny any



!--- Restricts the IP addresses for the peers 
!--- and clients.


ntp access-group peer 5


!--- Fault tolerant configuration polling 2 
!--- local time servers and 1 local peer.


ntp server <CB-1>
ntp server <CB-2>
ntp peer <dl-2>

Campus-Zeitverteilungsnetzwerk mit niedriger Schicht

Im folgenden Diagramm wird eine GPS- oder Cäsium-Zeitquelle im zentralen Rechenzentrum für das Campus-Netzwerk der unteren Schicht bereitgestellt. Dadurch wird eine Schicht-1-Zeitquelle im privaten Netzwerk bereitgestellt. Wenn sich im privaten Netzwerk mehrere GPS- oder Cäsium-Zeitquellen befinden, muss die Zeitverteilung im privaten Netzwerk geändert werden, um die verfügbaren Zeitquellen zu nutzen.

Im Allgemeinen gelten die gleichen Prinzipien und Konfigurationen wie in den vorherigen Beispielen. Der Hauptunterschied besteht in diesem Fall darin, dass der Stamm des Synchronisationsbaums eine private Zeitquelle und keine öffentliche Zeitquelle aus dem Internet ist. Dadurch wird das Design des Zeitverteilungsnetzwerks geändert, um die Vorteile der hochpräzisen privaten Zeitquelle zu nutzen. Die private Zeitquelle ist über das private Netzwerk verteilt, wobei die in den vorherigen Abschnitten beschriebenen Prinzipien der Hierarchie und Modularität beachtet werden.

Campus-Zeitverteilungsnetzwerk mit niedriger Schicht

Prozessdefinitionen

Eine Prozessdefinition ist eine verbundene Reihe von Aktionen, Aktivitäten und Änderungen, die von Agenten ausgeführt werden, die einen Zweck erfüllen oder ein Ziel erreichen möchten. Prozesssteuerung ist der Prozess der Planung und Regelung mit dem Ziel, einen Prozess effektiv und effizient durchzuführen. Dies wird im nächsten Diagramm veranschaulicht. 

Reihe von Prozessen

Die Ergebnisse des Prozesses müssen den betrieblichen Normen entsprechen, die von einer Organisation definiert werden und auf den Geschäftszielen basieren. Wenn der Prozess den festgelegten Normen entspricht, wird er als effektiv betrachtet, da er wiederholt, gemessen und verwaltet werden kann und zur Erreichung der Geschäftsziele beiträgt. Wenn die Aktivitäten mit einem minimalen Aufwand durchgeführt werden, wird das Verfahren ebenfalls als effizient angesehen.

Prozesseigentümer

Prozesse umfassen verschiedene organisatorische Grenzen. Daher ist es wichtig, dass nur ein Prozesseigentümer für die Definition des Prozesses verantwortlich ist. Der Verantwortliche ist der zentrale Ansprechpartner, der feststellt und meldet, ob der Prozess effektiv und effizient ist. Wenn der Prozess nicht effektiv oder effizient ist, wird die Änderung des Prozesses vom Prozesseigner durchgeführt. Die Änderung des Prozesses wird durch Änderungskontroll- und Überprüfungsprozesse geregelt.

Ziele des Prozesses

Es werden Prozessziele festgelegt, um die Richtung und den Umfang für die Prozessdefinition festzulegen. Ziele werden auch verwendet, um Metriken zu definieren, mit denen die Effektivität eines Prozesses gemessen wird.

Ziel dieses Prozesses ist es, Kriterien bereitzustellen, die während der NTP-Entwurfsphase dokumentiert werden müssen, und eine Prüffunktion für eine bereitgestellte NTP-Architektur bereitzustellen, um die langfristige Konformität mit dem beabsichtigten Design sicherzustellen.

Leistungsindikatoren für Prozesse

Anhand von Prozessleistungsindikatoren wird die Effektivität der Prozessdefinition gemessen. Die Leistungsindikatoren müssen messbar und quantifizierbar sein. Die als Nächstes aufgeführten Leistungsindikatoren sind beispielsweise entweder numerisch oder werden nach Zeit gemessen.

• Die zum Durchlaufen des gesamten Prozesses erforderliche Zeitdauer.

• Die Häufigkeit der Ausführung, die erforderlich ist, um NTP-Probleme proaktiv zu erkennen, bevor sie sich auf die Benutzer auswirken.

• Die Netzwerkauslastung, die mit der Ausführung des Prozesses verbunden ist.

• Die Anzahl der vom Prozess empfohlenen Korrekturmaßnahmen

• Die Anzahl der Korrekturmaßnahmen, die als Ergebnis des Prozesses durchgeführt wurden.

• Der Zeitraum, der für die Durchführung von Korrekturmaßnahmen benötigt wird.

• Der Rückstand bei den Korrekturmaßnahmen.

• Die Fehler bei der Fehlerbehebung oder Problemdiagnose werden auf NTP-bezogene Probleme zurückgeführt.

• Die Anzahl der in der Seed-Datei hinzugefügten, entfernten oder geänderten Elemente. Dies ist ein Zeichen für Genauigkeit und Stabilität.

Eingaben verarbeiten

Prozesseingaben werden verwendet, um Kriterien und Voraussetzungen für einen Prozess zu definieren. Die Identifizierung von Prozesseingaben liefert häufig Informationen zu externen Abhängigkeiten. Als Nächstes wird eine Liste der Eingaben für das NTP-Management bereitgestellt.

• NTP-Designdokumentation

• Durch SNMP Polling erfasste NTP-MIB-Daten

Prozessausgaben

Die Prozessausgaben werden wie folgt definiert:

• NTP-Konfigurationsberichte, die im Abschnitt "Datenpräsentation" dieses Dokuments definiert sind

• NTP-Korrekturmaßnahmen

Aufgabendefinitionen

In den nächsten Abschnitten werden die Initialisierungs- und iterativen Aufgaben im Zusammenhang mit der NTP-Verwaltung definiert.

Initialisierungsaufgaben

Initialisierungsaufgaben werden während der Implementierung des Prozesses einmal ausgeführt und dürfen nicht während jeder Iteration des Prozesses ausgeführt werden.

Erstellen des NTP-Designs

Wenn Sie erforderliche Aufgaben überprüfen und feststellen, dass eine der Aufgaben nicht implementiert ist oder keine ausreichenden Informationen liefert, um die Anforderungen dieses Verfahrens effektiv zu erfüllen, muss diese Tatsache vom Prozesseigner dokumentiert und dem Management vorgelegt werden. In der nächsten Tabelle sind die erforderlichen Initialisierungsaufgaben aufgeführt.

Erforderliche Aufgabe	Beschreibung
Aufgabenziele	Erstellung eines detaillierten Designdokuments für die NTP-Architektur, das den Designanforderungen und Kostenzielen entspricht
Task-Eingaben	Technische und wirtschaftliche Anforderungen entwerfen Derzeitige Netzwerkdesign-Dokumentation Kriterien, die die im Design aufzuzeichnenden Aspekte definieren, um Managementfunktionen zu ermöglichen Informationen zur Bereitstellung von IT-Anwendungen Anforderungen an die Leistungsüberwachung
Aufgabenausgabe	NTP-Designdokumentation.
Aufgabenressourcen	Netzwerktechniker, Architekt für den Netzwerkbetrieb.
Aufgabenrollen	Technische Genehmigung des Netzwerkdesigns durch Prüfer für Technologie und Betrieb; Genehmigung der Netzwerkdesignkosten durch den zuständigen Budgetmanager

Seed-Datei erstellen

Für den NTP-Managementprozess muss eine Seed-Datei verwendet werden, damit keine Netzwerkerkennungsfunktion mehr erforderlich ist. Die Seed-Datei zeichnet die durch den NTP-Prozess gesteuerten Router auf und dient als zentrale Stelle für die Koordination mit den Change-Management-Prozessen in einer Organisation. Wenn beispielsweise neue Knoten in das Netzwerk eingegeben werden, müssen sie der NTP-Seed-Datei hinzugefügt werden. Wenn die SNMP-Community-Namen aufgrund von Sicherheitsanforderungen geändert werden, müssen diese Änderungen in der Seed-Datei übernommen werden. In der nächsten Tabelle wird beschrieben, wie Sie eine Seed-Datei erstellen.

Erforderliche Aufgabe	Beschreibung
Aufgabenziele	Erstellen Sie eine Seed-Datei, die drei Kategorien von Netzwerkgeräten identifiziert: Kritische Geräte - Häufig gestellte Fragen zu Konfigurationsinformationen Interessante Geräte - seltener Polling Alle NTP-fähigen Geräte - Abruf der geringsten Menge
Task-Eingaben	NTP-Design-Dokumentation Netzwerktopologie-Dokumentation.
Aufgabenausgabe	Seed-Datei
Aufgabenressourcen	Designkriterien, anhand derer die an der NTP-Architektur beteiligten Knoten identifiziert und priorisiert werden können

Grundlegende NTP-Leistungsparameter

Einige der für die Überwachung des NTP-Netzwerks verfügbaren Parameter weisen einige normale erwartete Schwankungen auf. Der Baselining-Prozess wird verwendet, um die normalen erwarteten Schwankungen zu charakterisieren und Schwellenwerte festzulegen, die unerwartete oder abnormale Bedingungen definieren. Mit dieser Aufgabe wird die Baseline für den variablen Parametersatz für die NTP-Architektur erstellt.

Prozess	Beschreibung
Aufgabenziele	Baseline-Variablenparameter
Task-Eingaben	Identifizieren variabler Parameter cntpSysRootDelay cntpSysRootDispersion cntpPeersRootDelay cntpPeersRootDispersion cntpPeersOffset cntpPeersDelay cntpPeersDispersion.
Task-Ausgaben	Basiswerte und Schwellenwerte.
Aufgabenressourcen	Tools, die SNMP-Daten erfassen und Basislinien berechnen.
Aufgabenrolle	Netzwerktechniker, NMS-Techniker.

Iterative Aufgaben

Iterative Tasks werden während jeder Iteration des Prozesses ausgeführt und deren Häufigkeit bestimmt und modifiziert, um die Leistungsindikatoren zu verbessern.

Seed-Datei verwalten

Die Seed-Datei ist für die effektive Implementierung des NTP-Managementprozesses von entscheidender Bedeutung. Daher muss der aktuelle Status der Seed-Datei aktiv verwaltet werden. Netzwerkänderungen, die sich auf den Inhalt der Seed-Datei auswirken, müssen vom NTP-Verwaltungsprozesseigentümer nachverfolgt werden.

Prozess	Beschreibung
Aufgabenziele	Beibehaltung der Genauigkeit der Seed-Datei
Task-Eingaben	Informationen zu Netzwerkänderungen
Task-Ausgaben	Startdatei
Aufgabenressourcen	Berichte, Benachrichtigungen, Meetings, die Änderungen betreffen
Aufgabenrolle	Netzwerktechniker - NMS-Techniker

NTP-Knotenscan durchführen

Sammeln Sie Informationen zu kritischen, interessanten und Konfigurations-Scans, die durch dieses Verfahren definiert werden. Führen Sie diese drei Scans mit unterschiedlichen Frequenzen aus.

Kritische Knoten sind Geräte, die als sehr wichtig für die Leistungs-Datensammlungspunkte angesehen werden. Der kritische Knotenscan wird häufig, z.B. stündlich oder bedarfsgesteuert vor und nach Änderungen durchgeführt. Interessante Knoten sind Geräte, die für die Gesamtintegrität der NTP-Architektur als wichtig erachtet werden, jedoch nicht in den Zeitsynchronisierungsbaum für die Erfassung kritischer Leistungsdaten aufgenommen werden können. Dieser Bericht wird periodisch, z.B. täglich oder monatlich, ausgeführt. Der Konfigurationsbericht ist ein umfassender und ressourcenintensiver Bericht, mit dem die gesamte NTP-Bereitstellungskonfiguration anhand von Design-Datensätzen charakterisiert wird. Dieser Bericht wird seltener erstellt, z. B. monatlich oder vierteljährlich. Ein wichtiger Punkt ist, dass die Häufigkeit der Berichterstellung an die beobachtete Stabilität der NTP-Architektur und die geschäftlichen Anforderungen angepasst werden kann.

Prozess	Beschreibung
Aufgabenziel	Überwachen der NTP-Architektur
Task-Eingabe	Netzwerkgerätedaten
Aufgabenausgabe	Berichte
Aufgabenressourcen	Softwareanwendungen zur Datenerfassung und Berichterstellung
Aufgabenrolle	Netzwerktechniker

NTP-Knotenberichte überprüfen

Für diese Aufgabe müssen kritische, interessante und Konfigurationsberichte geprüft und analysiert werden. Wenn Probleme erkannt werden, müssen Korrekturmaßnahmen eingeleitet werden.

Prozess	Beschreibung
Task-Eingaben	Scannen von Berichten
Task-Ausgaben	Stabilitätsanalyse Korrekturmaßnahmen
Aufgabenressourcen	Zugriff auf Netzwerkgeräte für weitere Untersuchungen und Verifizierungen
Aufgabenrolle	Netzwerktechniker

Datenidentifizierung

Allgemeine Dateneigenschaften

In der nächsten Tabelle werden Daten beschrieben, die bei der Analyse der NTP-Architektur als wichtig erachtet werden.

Daten	Beschreibung
Knoten-ID	Ein Gerät mit konfiguriertem NTP
Peers	Die konfigurierten Peers für das Gerät
Synchronisierungsquelle	Der ausgewählte Peer für die Synchronisierung
NTP-Konfigurationsdaten	Parameter zur Beurteilung der Konsistenz des NTP-Designs
NTP-Qualitätsdaten	Parameter zur Charakterisierung der Qualität der NTP-Verbindungen

SNMP-Datenidentifizierung

Cisco NTP MIB-Systemgruppe

Die NTP-SNMP-Daten werden von Cisco-NTP-MIB definiert. Aktuelle Informationen zu den Versionen, die diese MIB unterstützen, finden Sie im CCO Feature Navigator. Wählen Sie dort die Option MIB Locator (MIB-Locator). Der Zugriff auf dieses Tool erfolgt über die Seite TAC Tools for Voice, Telefony and Messaging Technologies (TAC-Tools für Sprach-, Telefonie- und Messaging-Technologien).

Die Systemgruppe in der Cisco NTP MIB stellt Informationen für den Zielknoten bereit, auf dem NTP ausgeführt wird. Der Zielknoten ist das Ziel der SNMP-Abfragen.

Objektname	Objektbeschreibung
cntpSysStratum	Schicht der lokalen Uhr. Wenn der Wert auf 1 (eine primäre Referenz) festgelegt ist, wird die in Abschnitt 3.4.6 in RFC-1305 beschriebene Primary-Clock-Prozedur ausgeführt. wird aufgerufen. ::= { cntpSystem 2 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.1.2
cntpSysPrecision	Vorzeichenbehaftete Ganzzahl, die die Genauigkeit der Systemuhr in Sekunden bis zur nächsten Potenz von zwei angibt. Der Wert muss auf die nächstgrößere Potenz von zwei gerundet werden. Beispielsweise wird einem 50-Hz- (20 ms) oder 60-Hz- (16,67 ms) Hochfrequenztakt der Wert -5 (31,25 ms), während einem 1000-Hz- (1 ms) Kristalltakt der Wert -9 (1,95 ms) zugeordnet wird. ::= { cntpSystem 3 } Objektkennung = .1.3.6.1.4.1.9.9.168.1.1.3
cntpSysRootDelay	Eine mit Vorzeichen versehene Festpunktzahl, die die gesamte Round-Trip-Verzögerung in Sekunden an die primäre Referenzquelle im Stamm des Synchronisierungs-Subnetzes angibt. ::= { cntpSystem 4 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.1.4
cntpSysRootDispersion	Der maximale Fehler in Sekunden, relativ zur primären Referenzquelle im Stamm des Synchronisierungs-Subnetzes. Es sind nur positive Werte größer Null möglich. ::= { cntpSystem 5 } Objektkennung = .1.3.6.1.4.1.9.9.168.1.1.4
cntpSysReferenzzeit	Die lokale Zeit, zu der die lokale Uhr zuletzt aktualisiert wurde. Wenn die lokale Uhr noch nie synchronisiert wurde, ist der Wert Null. ::= { cntpSystem 7 } Objektkennung = .1.3.6.1.4.1.9.9.168.1.1.7
cntpSysPeer	Die aktuelle Synchronisierungsquelle, die den eindeutigen Zuordnungsbezeichner cntpPeersAssocId des entsprechenden Peereintrags in der cntpPeersVarTable des Peers enthält, der als Synchronisierungsquelle fungiert. Wenn kein Peer vorhanden ist, ist der Wert 0. ::= { cntpSystem 9 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.1.9
cntpSystemuhr	Die aktuelle Ortszeit Die Ortszeit wird aus der Hardware-Uhr der jeweiligen Maschine abgeleitet und erhöht sich in Intervallen, je nach verwendetem Design. ::= { cntpSystem 10 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.1.10

Cisco NTP MIB-Peer-Gruppe - Tabelle mit Peers-Variablen

Die Peer-Gruppe der Cisco NTP MIB stellt Informationen zu den Peers des Zielknotens bereit.

Objektname	Objektbeschreibung
cntpPeersVarTabelle	Diese Tabelle enthält Informationen zu den Peers, denen der lokale NTP-Server zugeordnet ist. Die Peers sind auch NTP-Server, die auf verschiedenen Hosts ausgeführt werden. Dies ist eine Tabelle mit cntpPeersVarEntry ::= { cntpPeers 1 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1
cntpPeersVarEintrag	Jeder Peer-Eintrag enthält NTP-Informationen, die von einem bestimmten Peer-NTP-Server abgerufen werden. Jeder Peer wird durch eine eindeutige Zuordnungs-ID identifiziert. Einträge werden automatisch erstellt, wenn der Benutzer den NTP-Server so konfiguriert, dass er Remote-Peers zugeordnet wird. Ebenso werden Einträge gelöscht, wenn der Benutzer die Peer-Zuordnung vom NTP-Server entfernt. Einträge können auch von der Verwaltungsstation erstellt werden, indem Werte für cntpPeersPeerAddress, cntpPeersHostAddress, cntpPeersMode festgelegt werden und cntpPeersEntryStatus als aktiv (1) festgelegt wird. Zumindest muss die Verwaltungsstation einen Wert für "cntpPeersPeerAddress" festlegen, um die Zeile zu aktivieren. INDEX { cntpPeersAssocId } ::= { cntpPeersVarTable 1 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1.1
cntpPeersAssocID	Eine Ganzzahl größer als Null, die einen Peer eindeutig identifiziert, dem der lokale NTP-Server zugeordnet ist. ::= { cntpPeersVarEntry 1 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1.1.1
cntpPeersKonfiguriert	Dies ist ein Hinweis darauf, dass die Verknüpfung aus Konfigurationsinformationen erstellt wurde und nicht getrennt werden darf, auch wenn der Peer nicht erreichbar ist. ::= { cntpPeersVarEntry 2 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1.1.2
cntpPeersPeerAdresse	Die IP-Adresse des Peers. Wenn eine neue Zuordnung erstellt wird, muss ein Wert für dieses Objekt festgelegt werden, bevor die Zeile aktiviert wird. ::= { cntpPeersVarEntry 3 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1.1.3
cntpPeersModus	SYNTAX INTEGER { unspecified (0), symmetricActive (1), symmetricPassive (2), client (3), server (4), broadcast (5), reservedControl (6), reservedPrivate (7) } Wenn eine neue Peer-Zuordnung erstellt wird und kein Wert für dieses Objekt angegeben wird, wird standardmäßig symmetricActive (1) verwendet. ::= { cntpPeers VarEntry 8 } object identifier = .1.3.6.1.4.1.9.9.168.1.2.1.1.8
cntpPeersSchicht	Die Schicht der Gegenstelle. ::= { cntpPeersVarEntry 9 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1.1.9
cntpPeersRootDelay	Eine mit Vorzeichen versehene Festpunktzahl, die die gesamte Round-Trip-Verzögerung in Sekunden angibt, vom Peer zur primären Referenzquelle im Stamm des Synchronisierungs-Subnetzes. ::= { cntpPeersVarEntry 13 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1.1.13
cntpPeersRootDispersion	Der maximale Fehler (in Sekunden) der Peer-Uhr relativ zur primären Referenzquelle im Root des Synchronisierungs-Subnetzes. Es sind nur positive Werte größer Null möglich. ::= { cntpPeersVarEntry 14 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1.1.14
cntpPeersRefZeit	Die lokale Zeit am Peer, als die Uhr zuletzt aktualisiert wurde. Wenn die Peer-Uhr noch nie synchronisiert wurde, ist der Wert Null. ::= { cntpPeersVarEntry 16 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1.1.16
cntpPeersReichweite	Ein Schieberegister, das zur Bestimmung des Erreichbarkeitsstatus des Peers verwendet wird, mit Bits, die vom Ende mit der geringsten Bedeutung (ganz rechts) eingehen. Ein Peer gilt als erreichbar, wenn mindestens ein Bit in diesem Register auf Eins gesetzt ist (Objekt ist ungleich null). Die Daten im Schieberegister werden von den NTP-Protokollprozeduren aufgefüllt. ::= { cntpPeersVarEntry 21 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1.1.21
cntpPeersOffset	Der geschätzte Offset der Peer-Uhr relativ zur lokalen Uhr in Sekunden. Der Host bestimmt den Wert dieses Objekts, das den NTP-Taktfilteralgorithmus verwendet. ::= { cntpPeersVarEntry 23 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1.1.21
cntpPeersVerzögerung	Die geschätzte Round-Trip-Verzögerung der Peer-Uhr relativ zur lokalen Uhr über den Netzwerkpfad zwischen den beiden Geräten in Sekunden. Der Host bestimmt den Wert dieses Objekts, das den NTP-Taktfilteralgorithmus verwendet. ::= { cntpPeersVarEntry 24 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1.1.24
cntpPeersDispersion	Der geschätzte maximale Fehler der Peer-Uhr im Verhältnis zur lokalen Uhr über den Netzwerkpfad zwischen den beiden Geräten in Sekunden. Der Host bestimmt den Wert dieses Objekts, das den NTP-Taktfilteralgorithmus verwendet. ::= { cntpPeersVarEntry 25 } Objektbezeichner = .1.3.6.1.4.1.9.9.168.1.2.1.1.25

Datensammlung

SNMP-Datensammlung

Alle für dieses Verfahren erforderlichen Informationen können über SNMP-Abfragen gesammelt werden. Um die Daten zu analysieren und die Reports zu erstellen, müssen angepasste Skripte oder Softwareprogramme entwickelt werden.

Datenpräsentation

Bericht zu kritischen NTP-Knoten

Kritische Knoten sind Geräte, die im Synchronisierungsbaum ausgewählter Leistungs-Datensammlungspunkte wichtig sind. Wenn ein umsatzstarker VoIP-Service überwacht wird und Kennzahlen für die unidirektionale Verzögerung und Variation erfasst werden, gelten die Quell- und Zielknoten, in denen die Zeitstempel aufgezeichnet werden, als kritische Knoten.

In diesem Beispiel wurde das NTP-Design als Nächstes einer OSPF-Beispielhierarchie festgelegt. Daher werden die nachfolgend beschriebenen Berichte formatiert, um die NTP-Geräte nach dem OSPF-Bereich des Geräts zu gruppieren. In Fällen, in denen ein Knoten Schnittstellen in mehreren Bereichen aufweist, muss von der Berichterstellungssoftware entschieden werden, in welchem Bereich der Knoten zu Berichtszwecken aufgeführt werden kann. Wie bereits erwähnt, ist OSPF keine Voraussetzung für NTP. Es wird in diesem Dokument nur als anschauliches Beispiel verwendet.

Bereich	"Slot0:"	Gerätedaten	Wert
AreaId #n	Geräte-ID #1	cntpSysStratum
		cntpSysPrecision
		cntpSysRootDelay
		cntpSysRootDispersion
		cntpSysReferenzzeit
		cntpSysPeer
		cntpSystemuhr
	Geräte-ID #n	cntpSysStratum
		cntpSysPrecision
		cntpSysRootDelay
		cntpSysRootDispersion
		cntpSysReferenzzeit
		cntpSysPeer
		cntpSystemuhr

NTP-Bericht zu interessanten Knoten

Das Format des interessanten Knotenberichts entspricht dem Format für den kritischen Knotenbericht. Interessante Knoten sind Knoten, die für die allgemeine NTP-Architektur wichtig sind, aber nicht direkt zur Zeitsynchronisierung wichtiger Performance-Überwachungspunkte beitragen können.

NTP-Konfigurationsbericht

Der Konfigurationsbericht ist ein umfassender Bericht, der Informationen über die gesamte NTP-Architektur erfasst. Dieser Bericht wird verwendet, um die NTP-Bereitstellung anhand der Design-Datensätze aufzuzeichnen und zu überprüfen.

Bereich	"Slot0:"	Peer	Peer-Daten	Wert
AreaId #n	Geräte-ID #n	Peer-ID #1	cntpPeersAssocID
			cntpPeersKonfiguriert
			cntpPeersPeerAdresse
			cntpPeersModus
			cntpPeersSchicht
			cntpPeersRootDelay
			cntpPeersRootDispersion
			cntpPeersRefZeit
			cntpPeersReichweite
			cntpPeersOffset
			cntpPeersVerzögerung
			cntpPeersDispersion
		Peer-ID #n	cntpPeersAssocID
			cntpPeersKonfiguriert
			cntpPeersPeerAdresse
			cntpPeersModus
			cntpPeersSchicht
			cntpPeersRootDelay
			cntpPeersRootDispersion
			cntpPeersRefZeit
			cntpPeersReichweite
			cntpPeersOffset
			cntpPeersVerzögerung
			cntpPeersDispersion

Zugehörige Informationen

• RFC 1305 Network Time Protocol
• RFC 2330-Framework für IP-Leistungsmetriken
• Grundlegende Cisco IOS-Funktionen v2.84 für jeden ISP
• Technischer Support und Downloads von Cisco