Konfigurieren der Uhreneinstellungen auf POS-Router-Schnittstellen

Einführung

In diesem Dokument werden die empfohlenen Uhrenquelleneinstellungen für über Dark Fiber, Back-to-Back oder ein Telco-Netzwerk verbundene PoE-Router-Schnittstellen (Packet over SONET) vorgestellt.

Wählen Sie die besten Uhreneinstellungen aus, um eine genaue Datenwiederherstellung zu gewährleisten und SONET-Layer-Fehler zu vermeiden.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

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

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Empfohlene Uhreneinstellungen für Router-POS-Schnittstellen

In dieser Tabelle sind die empfohlenen Uhreneinstellungen für Router-POS-Schnittstellen zusammengefasst:

Im weiteren Verlauf dieses Dokuments werden die Gründe für die empfohlenen Einstellungen erläutert.

Konfiguration 1: Back-to-Back, Dark Fiber oder DWDM

Cisco empfiehlt, in dieser Konfiguration die interne Konfiguration oder die Konfiguration der internen Konfiguration bzw. der internen Verbindung zu internen Geräten zu konfigurieren. Legen Sie nicht fest, dass beide Seiten die Taktgebung von der Leitung in dieser Konfiguration ableiten, um Frequenzschwankungen und Leitungsunterbrechungen, einschließlich zeitweiliger Fehler und sogar Verbindungsausfälle, zu vermeiden.

Um zwei Router für eine Back-to-Back-Verbindung zu konfigurieren, verwenden Sie den Befehl clock source internal.

interface POS0/0 
  ip address 5.0.2.1 255.255.255.0
  clock source internal

interface POS1/0
  ip address 5.0.2.2 255.255.255.0
  clock source internal

Warum intern?

In diesem Abschnitt wird erläutert, wie wichtig interne Verbindungen für eine Back-to-Back- oder Dark-Fiber-Konfiguration sind. Abbildung 1 zeigt eine Back-to-Back-Topologie.

Abbildung 2 zeigt eine POS-Verbindung über Dark Fiber.

Ein häufiges Missverständnis bezüglich der Taktgebung besteht darin, dass beide Enden einer synchronen Verbindung dieselbe Uhr verwenden müssen, sodass ein Ende die Taktgebung von der Leitung ableiten muss. Diese Aussage gilt für DCE-zu-DTE-Verbindungen. Diese Aussage gilt jedoch nicht für bidirektionale Layer-1-Verbindungen, wie SONET.

Es folgt ein Beispiel, um zu erläutern, warum diese Aussage nicht für bidirektionale Layer-1-Links geeignet ist:

Hier wird jede unidirektionale Verbindung synchronisiert.

• Der rechte SONET-Empfänger (Rx) ist mit dem linken SONET-Sender (Tx) synchronisiert.

• Der linke SONET-Empfänger ist synchron mit dem rechten SONET-Sender.

Beide Einwegverbindungen müssen jedoch nicht miteinander synchronisiert werden. Mit anderen Worten, die Verbindung von links nach rechts muss nicht mit der Verbindung von rechts nach links synchronisiert werden.

Eine POS-Schnittstelle besteht aus zwei physischen Glasfasersträngen. Jeder Strang bietet eine unidirektionale Verbindung.

Wichtig ist, dass der Router bei interner Taktquelle folgende Aktionen durchführt:

• Der Sender verwendet die interne Uhr, um das Übertragungssignal zu übermitteln.

• Der Empfänger verwendet immer die von der Empfangsleitung wiederhergestellte Uhr zur Synchronisierung mit dem Sender am Remote-Ende.

Daher können Sie die interne Taktgebung auf beiden Routerenden konfigurieren. Der Befehl clock source bestimmt nur die Quelle der Übertragungs-Uhr.

Eine paketbasierte Anwendung von SONET - und jeder SONET-basierten Point-to-Point-Konfiguration - unterstützt interne Uhreneinstellungen entweder mit Stratum 3- oder Stratum 4-Oszillatoren. Die Uhren müssen die SONET Minimum Clock (SMC)-Spezifikation erfüllen, die eine Genauigkeit von 20 Teilen pro Million (ppm) festlegt. Die ursprünglichen SONET-Netzwerke, die Punkt-zu-Punkt-OC-48-Verbindungen unterstützten, die in der Regel DS-3-Frames trugen, und die Pre-SONET Plesiochronous Digital Hierarchy (PDH)-Netzwerke wurden ebenfalls mit 20 ppm-Uhren ausgestattet. Diese frühen SONET-Systeme sind eine direkte Analogie zu den heutigen POS-Verbindungen, die eine Punkt-zu-Punkt-Verbindung zwischen zwei Routern mit asynchronen Schnittstellen zum Rest des Netzwerks definieren.

Point-to-Point bedeutet, dass die SONET-Nutzlast an jeder POS-Schnittstelle endet. Der Router extrahiert anschließend IP-Pakete aus dem gekapselten PPP-Frame und leitet die Pakete an eine Ausgabeschnittstelle weiter, als ob alle Nicht-POS-Schnittstellen, wie eine serielle oder Ethernet-Schnittstelle, die Pakete empfangen würden. Das bedeutet, dass Sie jede POS-Verbindung unabhängig voneinander zeitlich festlegen können und nicht alle POS-Schnittstellen auf einem Router mit einer gemeinsamen Uhr synchronisiert sein müssen.

Die POS-Zuordnung verwendet HDLC-ähnliches Framing und füllt die Lücken zwischen aufeinander folgenden Paketen mit inaktiven Flags auf. Auf diese Weise wird die IP-Nutzlastrate von der SONET-Frame-Rate abgekoppelt. Für die Zuordnung ist keine extrem genaue Uhr erforderlich, um die ausgehende SONET-Frame-Rate zu generieren, und eine Genauigkeit von 20 ppm ist mehr als ausreichend. Die riesigen Puffer, die die Empfangsschnittstellen verwenden, minimieren die Auswirkungen von übermäßigem Jitter.

Multi-Node SONET-Netzwerke können Payloads auch zuverlässig mit interner Taktgebung transportieren, die an jedem Knoten konfiguriert ist, wenn die Uhren mindestens Stratum-3-genau sind. Cisco empfiehlt eine solche Konfiguration jedoch nicht. Die genauen Uhren in Stratum 4 können zu einer hohen Anzahl von Zeigerbegründungen führen, die dazu führen können, dass die Jitter-Toleranz der gehosteten asynchronen Geräte überschritten wird.

Berücksichtigen Sie bei der Auswahl einer Taktrate für Back-to-Back- oder Dark-Fiber-POS-Verbindungen die folgenden Punkte:

• POS definiert eine Point-to-Point-Technologie. Der SONET-Link endet vollständig auf der Linecard. Es werden keine SONET-Informationen zwischen den Ports eines Routers weitergeleitet. Im Gegensatz dazu übergibt ein SONET Add-Drop-Multiplexer (ADM) in der Regel den synchronen Payload-Umschlag (SPE) vom Eingangs- zum Ausgangsport und ändert die Pointer-Bytes, um einen Timing-Offset zwischen den beiden Ports aufzunehmen.

• POS verwendet eine asynchrone Zuordnung. Der SONET-Frame bestimmt die Geschwindigkeit, mit der Pakete Byte für Byte in SONET-Frames "gefüllt" werden. Auf der Übertragungsseite legt eine Router-POS-Schnittstelle die H1/H2-Zeigerbyte auf einen festen Wert von 522 fest. Dieser Wert wird gewählt, weil der Zeigerwert die SPE am Anfang des Frames positioniert, der den Zeigern folgt. Framer-Designer müssen einen beliebigen Wert auswählen, sodass sie tendenziell "nette" Werte wie 522 auswählen. In einer Dark Fiber- oder DWDM-Konfiguration enthält der Pfad keine Geräte, die die Zeigerbyte ändern oder verarbeiten. Der SONET-Frame erreicht also den Empfänger mit demselben festen Wert von 522 für die H1/H2-Byte. Es besteht daher keine Möglichkeit, Slips oder SPE-Slips zu halten.

Wann soll man zwischen internen Leitungen wählen?

Alternativ können Sie ein Ende des Links für die Taktquelle konfigurieren. Das Ergebnis dieser Konfiguration ist, dass der Sender jetzt die Uhr verwendet, die vom lokalen Empfänger von der Leitung wiederhergestellt wurde, um das übertragene Signal zu speichern.

Konfigurieren Sie die Taktquelle an einem Ende (und nur an einem Ende) Ihrer POS-Verbindung, wenn die abgeleitete Taktquelle eine höhere Qualität hat als die Uhr, die auf der POS-Schnittstelle des Routers verfügbar ist. Line Cards der Engine 3 und Engine 4 der Cisco Serie 12000 verwenden eine Stratum 3-Taktquelle. Alle Line Cards der Engine 0 - 2, die nicht die 1xOC48 SRP-Linecard (OC48/SRP-SR-SC-B) sind, verwenden eine SMC-Quelle. Ein Nebenprodukt einer leitungsinternen Konfiguration besteht darin, dass beide Richtungen der Verbindung dieselbe Uhr verwenden, dies muss jedoch nicht der Grund sein.

Der Nachteil von line-internal ist, dass ein Taktschlag in eine Richtung dazu führt, dass die Schnittstelle versucht, sich selbst von der Leitung abzuschalten, um Fehler zu senden, da sie nun ein "schlechtes" Signal als Quelle verwendet. Intern trennt die beiden Uhren-Domänen. Ein Fehler auf der einen Seite führt auf der anderen Seite nicht zu einem Fehler. Durch die Blockierung der internen Daten auf beiden Seiten wird sichergestellt, dass ein Fehler in der empfangenen Uhr (auf Schleifenseite) den Tx-Datenverkehr nicht beeinträchtigt.

Die bisherige Diskussion zeigt, dass die Konfiguration der Taktquelle auf beiden Enden einer POS-Verbindung von Natur aus instabil ist. Bei Line-to-Line-Verbindungen verwenden beide Sender die Uhr, die vom Remote-Ende empfangen wurde, und keines der beiden Endgeräte liefert die Uhr tatsächlich. Diese falsche Konfiguration führt zu einer Zeitschleife.

Hinweis: Bei einer begrenzten Charge von 1xOC12 POS Line Cards für die GSR traten zeitabhängige Fehler auf, die auf ein Problem mit dem Onboard-Oszillator zurückzuführen sind. Der Oszillator benötigte eine identische eingehende und ausgehende Uhr. Aus diesem Grund wurden die meisten zeitbezogenen Fehler durch entsprechende, leitungsinterne Uhreneinstellungen behoben. Dieses Problem betrifft keine anderen POS-Linecards.

Konfiguration 2: Verbindung über eine SONET-Cloud

Bei dieser Konfiguration empfiehlt Cisco, beide Seiten so zu konfigurieren, dass die Taktgebung von der Leitung abgeleitet wird. Die POS-Schnittstellen des Cisco Routers verwenden standardmäßig das Lineccking. Konfigurieren Sie die Taktquelle, wenn Sie die Zeiteinstellung zuvor geändert haben.

Abbildung 4 zeigt eine POS-Verbindung über ein SONET-Netzwerk.

In der Regel bietet die SONET-Cloud eine genauere oder höhere Stratum-Level-Taktquelle als die Router-Hardware. In seltenen Fällen erhöht eine POS-Schnittstelle die PSE-/NSE-Zähler und meldet Zeigeranpassungen mit Zeigertaktung. Solche Zeigeranpassungen weisen auf ein Problem mit Zeitabweichungen oder Uhrzeitabweichungen im Anbieternetzwerk hin. Melden Sie solche Probleme dem Anbieter.

Zugehörige Informationen

• Packet-over-SONET/SDH
• Support-Seiten für optische Technologie
• Technischer Support und Dokumentation - Cisco Systems

Revisionsverlauf