Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrund

Precision Time Protocol (PTP)

Einführung

Protokoll

Master- und Slave-Timestamp-Exchange-Prozess

GrandMaster-Uhr

Slave-Uhr

Grenzuhr

Uhrenklassen

Uhrstatus

PTP-Domänen

PTP-Profile

Definition von Basisnachrichten

Anforderungen

Konfiguration

PTP Master Clock für ASR900

Schritt 1: Konfigurieren des lokalen internen Oszillators

Schritt 2: Konfigurieren Sie PTP als Master auf dem ASR900.

Überprüfung

Slave Clock auf cBR-8

Überprüfung

Einschränkungen

Das G.8275.2-Profil

Slave-Uhr auf RPD

Überprüfung

Grenzuhr auf ASR900

Überwachen mit SNMP

Fehlerbehebung

Fehlerbehebung beim PTP-Master (ASR900)

Fehlerbehebung beim PTP-Slave (cBR-8)

DTI und PTP

Uhrzeitverzögerungen und Offset

Fehlerbehebung beim PTP-Slave (RPD)

Zugehörige Informationen

Einführung

Dieses Dokument beschreibt das Precision Time Protocol (PTP), das in Kabelnetzwerken mit cBR-8- und Remote PHY-Netzwerken (R-PHY) verwendet wird. Ziel ist es, ein globales Verständnis des Protokolls und dessen Konfiguration in cBR-8- und RPHY-Bereitstellungen zu vermitteln.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

- R-PHY.

- cBR-8 Converged Cable Access Platform (CCAP)

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

- cBR-8 läuft ab Version 16.6.1.

- Cisco RPD (Remote PHY Device), 1 x 2.

Tipp: Weitere Informationen finden Sie im Artikel Cisco 1x2 RPD.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrund

Um Modems die Zeitschlitze (Minislots) für die Übertragung auf einem Upstream-Kanal zu gewähren, ordnet CCAP Upstream-Minislot-Zuweisungen mittels Upstream-MAP-Nachrichten (Bandbreitenzuweisung) zu. Diese MAP-Nachrichten werden im Downstream gesendet und von allen Modems empfangen.

Die Modems sehen sich diese Meldungen an, um zu ermitteln, welche Minislots welchen Modems zugewiesen sind und welche für konfliktbasierte Aktivitäten. Ein Modem überträgt Datenverkehr nur über einen ihm zugewiesenen Minislot (oder über einen Konfliktplatz, wenn es eine Bandbreitenanforderung oder eine andere Station-Wartungsaktivität sendet).

Die MAP-Nachrichten des CCAP weisen etwa 2 Millisekunden (ms) Zeit zu. DOCSIS (LLD) mit niedriger Latenz bietet Optionen zur Reduzierung dieses Werts unter 2 ms.

Um Überschneidungen zu vermeiden, müssen CCAP und jedes Modem das gleiche Zeitkonzept haben.

Die CCAP muss sicherstellen, dass sie einem Modem nach einer Anfrage nicht zu schnell einen Zeitschlitz zuweist, um zu verhindern, dass das Modem keine Zeit hat, die MAP-Nachricht zu empfangen und zu verarbeiten, und dass die Möglichkeit zur Verwendung dieses Minislots verpasst wird.

Um diese Situation zu vermeiden, verwendet der CCAP einen Timer für die vorzeitige MAP-Verarbeitung, bei dem der Datenverkehr für ein Modem erst zu einem Zeitpunkt nach dem vorzeitigen MAP-Timer geplant wird.

Das für die vorgelagerte Planung erforderliche Zeitelement des DOCSIS ist in R-PHY noch vorhanden. Zur Verbindung der RPDs mit dem CCAP wird ein Converged Interconnect Network (CIN) verwendet, das IP-basiert ist und für den Kabelzugriff reserviert oder von anderen Anwendungen gemeinsam genutzt werden kann.

Der CCAP-Core übernimmt die vorgelagerte Planung und Generierung von MAP-Nachrichten. Die Downstream- und Upstream-Signale beginnen und enden nun physisch auf der RPD, daher muss die RPD das gleiche Zeitkonzept haben wie der CCAP-Core.

Die Remote DOCSIS Timing Interface Specification (R-DTI) ist die Spezifikation von CableLabs, in der beschrieben wird, wie dieses Timing abläuft. Für Ethernet-basierte Netzwerke wird PTP verwendet, um dieses Timing zu erreichen.

In der aktuellen Implementierung von Cisco fungieren sowohl der cBR-8 als auch der RPD als Slave-Gerät für eine PTP-Referenzuhr.

Precision Time Protocol (PTP)

Einführung

PTP ermöglicht es einer Slave-Uhr, den Zeitversatz von einer Referenzuhr (Zeitdifferenz zwischen den Uhren) sowie die Übertragungsverzögerung im Transportnetzwerk zwischen den beiden Uhren zu bestimmen.

Die Master- und Slave-Geräte tauschen Nachrichten aus, die Zeitstempel enthalten, bevor der Slave einen Algorithmus zur Bestimmung dieser Werte ausführt.

Die Formeln für diese Berechnung gehen von einer symmetrischen Verbindung zwischen den beiden Uhren aus.

Warnung: Eine der Hauptursachen für DOCSIS-Probleme in R-PHY ist die nicht symmetrische PTP-Verbindung, die zu einer Instabilität der Uhr führt.

Nicht symmetrische Verbindungen wie das Ethernet Passive Optical Network (EPON) sind in der R-DTI-Spezifikation für die Verwendung als CIN aufgeführt, basieren jedoch auf einer anderen Zeitsteuerungsmethode, die derzeit von Cisco nicht unterstützt wird.

Die RPD-Funktion sollte die Referenzuhr über das CIN erreichen. Der cBR-8 kann über WAN-Schnittstellen (Wide Area Network) auf der Physical Interface Card (PIC) des Supervisors oder über Digital PIC (DPIC)-Schnittstellen auf der Line Card des Kabels auf die Referenzuhr zugreifen (die DPIC-Option wurde in Version 16.8.1 hinzugefügt). Es wird empfohlen, dass die RPD nicht den cBR-8 durchläuft, um auf die Referenzuhr zuzugreifen.

RPD und cBR-8 können in der aktuellen Software nur als Slave-Uhren funktionieren, obwohl die cBR-8 Roadmap die Unterstützung als primäre Referenzuhr und Boundle-Uhr bietet.

Hinweis: Sobald der cBR-8 so konfiguriert ist, dass er PTP zum Timing verwendet, verlassen sich alle Linecards auf diese Uhr, selbst Linecards mit RF-PICs.

Dies bedeutet, dass sich Probleme mit der PTP-Uhrenstabilität auf alle Modems in einem Chassis auswirken, auch auf Integrated CCAP (I-CCAP) Line Cards, wenn Sie eine Kombination von Karten in einem Chassis verwenden.

Protokoll

PTP ist gemäß IEEE-Standard 1588-2008 definiert.

Die vollständigen Spezifikationen finden Sie hier: 1588-2008 - IEEE Standard für ein Precision Clock Synchronization Protocol for Networked Measurement and Control Systems.

Hinweis: Sie benötigen registrierte Benutzer, um den vollständigen Zugriff auf das Dokument zu erhalten.

PTP ermöglicht die Verteilung von Zeit und Frequenz über ein Netzwerk:

- Zeit (Synchronisierung): Synchronisiert die Zeit zwischen Geräten in einem Netzwerk.

- Häufigkeit (Synchronisierung): Synchronisiert die Frequenz.

PTP verwendet Multicast- oder Unicast-Nachrichten und Ports UDP 319 (Für Ereignisse)- und UDP 320 (für allgemeine Meldungen).

Bei der CMTS-Implementierung verwendet PTP IPv4-Unicast.

Das Protokoll erstellt eine Master-Slave-Beziehung zwischen einer Großmaster-Uhr und Client-Geräten über das Netzwerk. PTP wählt eine Uhr für die Verteilung in einem Netzwerk mithilfe eines Algorithmus aus, der als Best Master Clock Algorithm (BCMA) bezeichnet wird.

Der Algorithmus bestimmt die beste Uhr in einem Netzwerk mit den folgenden Eigenschaften:

- Kennung (Nummer, die aus der MAC-Adresse des Geräts erstellt wurde, sieht in der Regel aus wie das Format EUI-64 (xxxx:xxFF:FExx:xxxx).

- Qualität.

- clockGenauigkeit: Bestimmt, wie genau die Uhr ist. Je geringer die Zeit, desto besser (desto genauer).

Value (hex) Specification

00-1F Reserved

20 The time is accurate to within 25 ns

21 The time is accurate to within 100 ns

22 The time is accurate to within 250 ns

23 The time is accurate to within 1 µs

24 The time is accurate to within 2.5 µs

25 The time is accurate to within 10 µs

26 The time is accurate to within 25 µs

27 The time is accurate to within 100 µs

28 The time is accurate to within 250 µs

29 The time is accurate to within 1 ms

2A The time is accurate to within 2.5 ms

2B The time is accurate to within 10 ms

2C The time is accurate to within 25 ms

2D The time is accurate to within 100 ms

2E The time is accurate to within 250 ms

2F The time is accurate to within 1 s

30 The time is accurate to within 10 s

31 The time is accurate to >10 s

32–7F Reserved

80–FD For use by alternate PTP profiles

FE Unknown

FF Reserved

- clockClass:Gibt die Nachvollziehbarkeit der Uhrzeit und Frequenz an, die von der GrandMaster-Uhr verteilt werden.
Uhrenklassen sind in den Spezifikationen IEEE 1588-2008 als solche definiert:

clockClass (decimal)-Spezifikation

0 Reserved to enable compatibility with future versions.

1–5 Reserved.

6 Shall designate a clock that is synchronized to a primary reference time source. The timescale distributed shall be PTP. A clockClass 6 clock shall not be a slave to another clock in the domain.

7 Shall designate a clock that has previously been designated as clockClass 6 but that has lost the ability to synchronize to a primary reference time source and is in holdover mode and within holdover specifications. The timescale distributed shall be PTP. A clockClass 7 clock shall not be a slave to another clock in the domain.

8 Reserved.

9–10 Reserved to enable compatibility with future versions.

11–12 Reserved.

13 Shall designate a clock that is synchronized to an application-specific source of time. The timescale distributed shall be ARB. A clockClass 13 clock shall not be a slave to another clock in the domain.

14 Shall designate a clock that has previously been designated as clockClass 13 but that has lost the ability to synchronize to an application-specific source of time and is in holdover mode and within holdover specifications. The timescale distributed shall be ARB. A clockClass 14 clock shall not be a slave to another clock in the domain.

15–51 Reserved.

52 Degradation alternative A for a clock of clockClass 7 that is not within holdover specification. A clock of clockClass 52 shall not be a slave to another clock in the domain.

53–57 Reserved.

58 Degradation alternative A for a clock of clockClass 14 that is not within holdover specification. A clock of clockClass 58 shall not be a slave to another clock in the domain.

59–67 Reserved.

68–122 For use by alternate PTP profiles.

123–127 Reserved.

128–132 Reserved.

133–170 For use by alternate PTP profiles.

171–186 Reserved.

187 Degradation alternative B for a clock of clockClass 7 that is not within holdover specification. A clock of clockClass 187 may be a slave to another clock in the domain.

188–192 Reserved.

193 Degradation alternative B for a clock of clockClass 14 that is not within holdover specification. A clock of clockClass 193 may be a slave to another clock in the domain.

194–215 Reserved.

216–232 For use by alternate PTP profiles.

233–247 Reserved.

248 Default. This clockClass shall be used if none of the other clockClass definitions apply.

249–250 Reserved.

251 Reserved for version 1 compatibility; see Clause 18.

252–254 Reserved.

255 Shall be the clockClass of a slave-only clock; see 9.2.2.

- Priorität - Ein administrativ zugewiesener Wert (zwischen 0 und 255)

- Abweichung - Die geschätzte Stabilität der Uhr

Master- und Slave-Timestamp-Exchange-Prozess

- Der Master sendet eine Synchronisierungsnachricht an den Slave und notiert die Uhrzeit (t1), zu der er gesendet wurde.

- Der Slave empfängt die Synchronisierungsmeldung und notiert die Uhrzeit des Empfangs (t2).

- Der Master überträgt dem Slave den Zeitstempel t1. es fügt den Timestamp t1 in eine Follow_Up-Meldung ein.

- Der Slave sendet eine Delay_Req-Nachricht an den Master und notiert die Uhrzeit (t3), zu der er gesendet wurde.

- Der Master empfängt die Nachricht Delay_Req und notiert die Uhrzeit des Empfangs (t4).

- Der Master überträgt dem Slave den Zeitstempel t4. sie wird in eine Delay_Resp-Nachricht eingebettet.

Dieser Prozess wird mehrmals pro Sekunde wiederholt (in der Regel 16 bis 32 Mal pro Sekunde), um eine schnelle Anpassung bei kleinen Offset-Änderungen zu gewährleisten.

GrandMaster-Uhr

Der GrandMaster kommuniziert mit den Sklaven, die Sitzungen mit dem Großmeister aufgebaut haben, um die Synchronisierungs- (Zeit) und Synchronisierungsinformationen an diese Slaves auszutauschen. Ein GrandMaster muss theoretisch mit einem PRTC (Prime Reference Time Clock) verbunden werden, wie z.B. über eine GPS-Antenne. Wenn ein GrandMaster ausfällt und ein anderer GrandMaster übernimmt, da beide die gleiche Zeitreferenz verwenden, verwenden die Slaves weiterhin die gleiche Zeitreferenz. Wenn Sie kein PRTC verwenden, führt der Ausfall einer GrandMaster-Uhr dazu, dass die Slaves die Zeitreferenz ändern, was in CMTS-Szenarien dazu führt, dass die Modems offline gehen.

Slave-Uhr

Der Slave initiiert die Verbindung mit der GrandMaster-Uhr. Sowohl Slave als auch Master tauschen ihre Konfigurationseinstellungen und Uhreneinstellungen aus, um die Aushandlung zu starten. In diesem Fall sind cBR-8 und RPD beide Slave zu einem externen PTP GrandMaster.

Warnung: Die aktuelle cBR-8-Bereitstellung (ab 16.10.1d) unterstützt nur cBR-8 als PTP-Slave. In der Zukunft wird möglicherweise eine PTP-Grenze oder ein PTP-Master angezeigt.

Grenzuhr

Die Boundary Clock synchronisiert zwei Netzwerksegmente miteinander. Funktioniert als Slave zu einer GM-Uhr auf Segment 1 und fungiert dann als GM-Uhr auf Segment 2. Nicht grenzübergreifende Uhren werden als "normale Uhren" bezeichnet.

Uhrenklassen

Uhrenklassen sind einer der Werte, die während der Aushandlung verwendet werden, um die Uhr in einem Netzwerk mit mehreren Uhren die genaueste zu finden.

Uhrenklassen sind durch IEEE 1588-2008 definiert.

Uhrstatus

- FREERUN: Keine Verbindung mit Remote-GM, verwendet lokalen Oszillator.

- HALBER: Verbindung mit einem Remote-GM verloren, versuchen Sie, diese wiederherzustellen, und versuchen Sie, die vorherige Uhr beizubehalten. Während des HOLDOVER-Zustands kann die Uhr anfangen zu driften, und wenn sie außerhalb der Spezifikationen treibt, geht sie zurück in den FREERUN-Modus.

- ERWERB: Verhandlung mit GM gestartet und Nachrichten mit dem GM ausgetauscht, um die vom Netzwerk verursachte Verzögerung zu ermitteln und eine Synchronisierung mit der GM-Uhr zu versuchen.

- FREQ_LOCKED: Das Slave-Gerät ist hinsichtlich der Frequenz auf den Master beschränkt, jedoch nicht phasengesteuert.

- PHASE_ALIGNED: An den Kapitän in Bezug auf Häufigkeit und Phase verriegelt.

Statusmaschine für RPD:

Hinweis: Bei RPHY-Bereitstellungen beträgt die unterstützte In-Spec-HOLDOVER-Zeit 10 Stunden (d. h. wenn cBR-8 oder RPD oder beide im HOLDOVER-Zustand sind). Während dieser Zeit bleiben die Modems online. Nach 10 Stunden HOLDOVER ist die interne Oszillatoruhr-Qualität nicht garantiert und Modems können aufgrund der Uhr von cBR-8, RPD oder beidem, die nicht spezifiziert sind, offline gehen.

PTP-Domänen

Die PTP-Domäne ist eine Zahl, die eine Gruppe von Geräten identifiziert, die miteinander kommunizieren. Slave- und Master-Geräte müssen sich in derselben PTP-Domäne befinden, damit sie miteinander synchronisiert werden können. Domäne 0 ist die Standarddomäne, und die Domänen 1-2-3 sind pro Spezifikation reserviert. Andere Domänennummern können 4-255 sein,

Beachten Sie, dass bei einigen PTP-Varianten wie G.8275.2 die PTP-Domäne im Bereich 44-63 liegen muss. Wenn Sie diese Variante nicht verwenden, vermeiden Sie die Verwendung dieses Bereichs von PTP-Domänen, da dies sowohl den Benutzer als auch das Gerät verwirren könnte.

PTP-Profile

PTP-Profile wurden in den IEEE-Standard 1588-2008 eingeführt und bestehen aus einer Reihe von Konfigurationsoptionen, die ausgewählt werden können, um die Anforderungen verschiedener Anwendungen zu erfüllen. Es ist möglich, separate Profile zu definieren, um PTP an verschiedene Szenarien anzupassen.

Beispiele für gängige PTP-Profile:

- Telecom-2008 Profil: Generisches Profil, das vor den Spezifikationen von G.8265.1 verwendet wurde. Dieses Profil verwendet die Domänennummern 0-4. Dieses Profil wird auf cBR-8 und RPD unterstützt, G.8275.2 wird jedoch dringend empfohlen, da es ausfallsicherer ist.

- G.8265.1: Precision Time Protocol Telecom-Profil für die Frequenzsynchronisierung

Dieses Profil ist für Anwendungen vorgesehen, die nur über Telekommunikationsnetzwerke eine Frequenzsynchronisierung erfordern. Die Phasenausrichtung und/oder Tageszeit werden nicht berücksichtigt.

Der Anwendungsfall wäre für PTP-Master und Slaves in Netzwerken, in denen die Zwischenknoten keine PTP-Unterstützung bieten.

Hinweis: Dieses Profil wird in der DOCSIS-Umgebung mit cBR-8 und RPD nicht unterstützt.

- G.8275.1: Precision Time Protocol Telecom-Profil für Phase-/Zeitsynchronisierung mit voller Timing-Unterstützung durch das Netzwerk

Dieses Profil wird bei Systemen verwendet, die eine genaue Synchronisierung der Zeit und Phase in Telekommunikationsnetzen erfordern (z. B. 4G-Mobilfunknetz oder RPD-Netzwerk), bei denen eine Phasensynchronisierung und/oder eine Synchronisierung der Tageszeit erforderlich ist.

Bei diesem Profil ist jedes Netzwerkgerät am PTP-Protokoll beteiligt. An jedem Knoten in der Kette zwischen PTP Grandmaster und PTP Slave wird eine Grenzuhr verwendet, was die Akkumulation von Zeitfehlern im Netzwerk reduziert.

- G.8275.2 : Precision Time Protocol Telecom-Profil für die Zeitsynchronisierung mit partieller Timing-Unterstützung aus dem Netzwerk

Dieses Profil basiert auf teilweiser Timing-Unterstützung durch das Netzwerk. Das bedeutet, dass die Knoten der PTP-Domäne nicht direkt verbunden werden müssen.

Wie G.8275.1 wird es in Systemen verwendet, die eine präzise Synchronisierung von Zeit und Phase erfordern, jedoch die Synchronisierung von Zeit und Phase über vorhandene Netzwerke ermöglichen. Bei Bedarf werden Grenzwertuhren verwendet, um das Zeitsignal im gesamten Netzwerk anzupassen.

Weitere Informationen zu G.8275.1 und G.8275.2 für die ASR900-Plattform finden Sie hier: Konfigurationsleitfaden für Timing und Synchronisierung, Cisco IOS XE Everest 16.5.1 (Cisco ASR Serie 900)

Definition von Basisnachrichten

- Sync, Follow_up, Delay_req, Delay_resp sind Nachrichten, die von der Grenze und normalen Uhren verwendet werden, um Zeitinformationen an Slaves im Netzwerk zu übermitteln.

- Ankündigungsnachrichten werden von Slaves und Master ausgetauscht, um die beste Uhr im Netzwerk mithilfe des Best Master Clock Algorithm zu identifizieren (siehe die Images 26, 27, 28 der IEEE-Spezifikationen für den detaillierten Mechanismus).

- Signalisierungsnachrichten werden für nicht zeitkritische Informationen verwendet.

Anforderungen

Diese Anforderungen müssen erfüllt sein, damit PTP in cBR-8 und R-PHY in einem Produktionsnetzwerk korrekt bereitgestellt werden kann:

- Verwenden Sie das PTP-Profil G.8275.2, um sicherzustellen, dass PTP auch dann funktioniert, wenn einige Netzwerkelemente im Pfad PTP nicht unterstützen.

- Keine Equal Cost Multi Path (ECMP), Load Balancing oder asymmetrischen Pfade: PTP geht immer davon aus, dass die Verzögerung vom Master zum Slave und umgekehrt gleich ist und innerhalb von 500 Mikrosekunden (µs)

- Konfigurieren Sie Verzögerungs-Aufgaben und Synchronisierungsintervalle mit den Werten -4 oder -5 (weitere Informationen finden Sie im Kapitel Konfiguration). Werte größer als -4 (-3, ...) bieten möglicherweise nicht genügend Genauigkeit, um kleine Offset-Änderungen zu erkennen. Werte unter -5 (-6, ...) haben eine höhere Auswirkung auf die Netzwerknutzung, aber keine signifikante Präzisionszunahme.

- Stellen Sie sicher, dass PTP-Pakete für RPD nicht durch cBR-8 geleitet werden.

- Stellen Sie einen minimalen Jitter im IP-Netzwerk (max. 1 ms) sicher. Auf allen Routern muss die richtige PTP-QoS angewendet werden: cBR-8 und RPD senden alle mit Differentiated Services Code Point (DSCP) 46 markierten PTP-Pakete (Express Forwarding - EF). Stellen Sie sicher, dass die PTP Grand Master-Uhr auch Pakete mit demselben DSCP-Wert markiert.

- Die PTP Grand Master-Uhr muss mit GPS synchronisiert sein und die Uhr-Klasse 6 melden, damit sie in einem Produktionsnetzwerk verwendet werden kann. Laborumgebungen können mit einem eigenständigen, kostenlosen PTP Grand Master (Takt-Klasse 58) ausgeführt werden.

- Die PTP Grand Master-Uhr muss eine Uhrengenauigkeit von 100 Nanosekunden aufweisen.

- Wenn zwei PTP Grand Master-Uhren verwendet werden, müssen Sie GPS verwenden, um die Synchronisierungszeit zwischen ihnen zu synchronisieren. Beide PTP Grand Masters müssen ihre Uhren innerhalb von 500 Mikrosekunden (µs) haben.

Hinweis: Ältere Versionen der RPD-Software verwenden möglicherweise DSCP-Werte von 47 - Neuere Versionen verwenden DSCP-Werte von 46 (EF) auf RPD, um CMTS-Werte zu berücksichtigen.

Konfiguration

In diesem Abschnitt wird beschrieben, wie Sie eine PTP-Referenzuhr auf einem Cisco ASR900-Router konfigurieren, die Slave-Uhr auf cBR-8 für cBR-8 selbst und RPD sowie eine Grenzuhr auf dem ASR900.

PTP Master Clock für ASR900

Es gibt unter Linux eine PTP-Protokoll-Basisimplementierung mit dem Namen "ptpd". Da es jedoch softwarebasiert ist, bietet es nicht genügend Präzision für die Arbeit mit cBR-8 und RPD, daher werden die Modems nicht online gehen können und auch die PTP-Synchronisierung wird nicht stattfinden. Darüber hinaus erfordert die PTPd-Linux-Implementierung eine Hardware-Zeitstempel durch die Netzwerkkarte, um die Genauigkeit zu erhöhen. Das bedeutet, dass PTPd bei Verwendung eines virtuellen Systems oder einer Netzwerkkarte, die keine Hardware-Zeitstempel unterstützt, unter Linux möglicherweise überhaupt nicht gestartet wird.

Je nach verwendetem ASR900-Modell verfügt das Gerät möglicherweise über eine GPS-Antenne. Wenn der ASR900 keine GPS-Antenne hat, haben Sie kein PRTC, aber Sie können den ASR900 weiterhin als Grandmaster mit einem lokalen PRTC (interner Oszillator) ausführen. Wenn dieser ASR900 ausfällt und ein anderer ASR900 den Betrieb übernimmt, verlieren cBR-8 und RPD die Zeitreferenz, da beide Uhren nicht wirklich synchronisiert sind.

Schritt 1: Konfigurieren des lokalen internen Oszillators

network-clock source quality-level QL-PRC tx

network-clock synchronization automatic

network-clock synchronization mode QL-enabled

network-clock synchronization squelch-threshold QL-PRC

network-clock quality-level tx QL-PRC ptp domain 0

network-clock input-source 1 External R0 10m

Schritt 2: Konfigurieren Sie PTP als Master auf dem ASR900.

ptp clock ordinary domain 0                             <<< DOMAIN 0 or DOMAIN 44 for G.8275.2

clock-port MASTER master [profile g8275.2]             <<< EITHER DEFAULT OR G.8275.2 PROFILE

sync interval -4

sync one-step

transport ipv4 unicast interface Lo1588 negotiation    <<< IPV4 UNICAST MODE, SOURCING PACKETS FROM LO1588 interface

interface Loopback1588

ip address 15.88.15.88 255.255.255.255

end

Hinweis: Wenn kein lokaler Oszillator oder GPS als Quelle konfiguriert ist, ist der PTP-Modus-Master nicht verfügbar.

Wenn Sie das G.8275.2-Profil in Ihrer Umgebung anstelle des Standardprofils verwenden, müssen Sie es in der Konfiguration des Uhrenports angeben (für die G.8275.2-Profilkonfiguration auf dem cBR-8 siehe Abschnitt: Das G.8275.2-Profil).

Beachten Sie, dass selbst wenn IOS-XE die Konfiguration des G.8265.1-Profils ermöglicht, dies in der DOCSIS-Umgebung mit cBR-8 und RPD nicht unterstützt wird.

Weitere Informationen zum G.8275.2-Profil auf dem ASR900 finden Sie in diesem Handbuch: Konfigurationsleitfaden für Timing und Synchronisierung, Cisco IOS XE Everest 16.5.1 (Cisco ASR Serie 900)

Überprüfung

Dieser Abschnitt enthält Informationen, mit denen Sie überprüfen können, ob Ihre Konfiguration ordnungsgemäß funktioniert.

ASR900#show ptp clock running

PTP Ordinary Clock [Domain 0]

State Ports Pkts sent Pkts rcvd Redundancy Mode

FREQ_LOCKED 1 86307034 36108234 Hot standby

PORT SUMMARY

PTP Master

Name Tx Mode Role Transport State Sessions Port Addr

MASTER unicast master Lo1588 Master 1 -

Hinweis: Bei der ersten Konfiguration des internen Oszillators muss der Oszillator vor der Stallung aufwärmen. Daher kann es eine Weile dauern, bis der Status des PTP FREQ_LOCKED ist. Dies kann bis zu 35 Minuten dauern.

ASR900#show ptp clock dataset parent

CLOCK [Ordinary Clock, domain 0]

Parent Clock Identity: 0x34:6F:90:FF:FE:C1:66:3F

Parent Port Number: 0

Parent Stats: No

Observed Parent Offset (log variance): 0

Observed Parent Clock Phase Change Rate: 0

Grandmaster Clock:

Identity: 0x34:6F:90:FF:FE:C1:66:3F

Priority1: 128

Priority2: 128

Clock Quality:

Class: 58

Accuracy: Within 1s

Offset (log variance): 52592

ASR900#show platform software ptpd stat stream 0

LOCK STATUS : FREERUN

SYNC Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval 0

Tx packets : 5577, Rx Packets : 0

Last Seq Number : 5577, Error Packets : 0

Delay Req Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval : 0

Tx packets : 0, Rx Packets : 5353

Last Seq Number : 0, Error Packets : 0

Delay Response Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval : 0

Tx packets : 5353, Rx Packets : 0

Last Seq Number : 0, Error Packets : 0

Announce Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval : 0

Tx packets : 1904, Rx Packets : 0

Last Seq Number 1904 Error Packets 0

Signalling Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval : 0

Tx packets : 1, Rx Packets : 1

Last Seq Number : 1, Error Packets : 0

Current Data Set

Offset from master : +0.0

Mean Path Delay : +0.0

Forward Path Delay : +0.0

Reverse Path Delay : +0.0

Steps Removed 0

General Stats about this stream

Packet rate : 0, Packet Delta (ns) : 0

Clock Stream handle : 0, Index : 0

Oper State : 0, Sub oper State : 6

Log mean sync Interval : 0, log mean delay req int : 0

Hinweis: Der interne Oszillator des ASR900 meldet standardmäßig die Klasse 58. Wenn Sie eine GM-Uhr eines Drittanbieters verwenden, können Sie auch die Taktklasse 6 sehen, wenn die Synchronisierung mit GPS erfolgt.

Slave Clock auf cBR-8

Der cBR-8 fungiert als CCAP-Core für das RPD und ist daher für die PTP-Konfiguration sowohl der eigenen als auch der zugehörigen RPDs verantwortlich.

Der cBR-8 verwendet Profile, um diese PTP-Informationen an die RPDs zu übertragen. Für PTP stehen mehrere konfigurierbare Optionen zur Verfügung:

- Der Servoortyp für den cBR-8 muss auf R-DTI gesetzt werden, um die Uhrensynchronisierung zu beschleunigen.

- Der cBR-8 verwendet eine benutzerdefinierte Loopback-Adresse als Quelle seiner PTP-Pakete. Vergewissern Sie sich, dass ein ordnungsgemäßes Routing für die Referenzuhr vorhanden ist, um die Loopback-Schnittstelle zu erreichen. Wenn Sie nicht in der Lage sind, einen Ping an die Referenzuhr zu senden, wenn ein Paket von der Loopback-Adresse stammt, ist das PTP nicht betriebsbereit.

- Das G.8275.2-Telekommunikationsprofil wird empfohlen, da es IPv4 und IPv6 unterstützt. Zwischengeschaltete Switching-Geräte im CIN müssen nicht PTP-fähig sein.

- Die PTP-Domänennummer wird vom Benutzer gewählt, muss jedoch für cBR-8 und die RPDs identisch sein.

PTP-Pakete werden mit einer höheren QoS sowohl von der RPD als auch von der cBR-8 für die Priorität auf der CIN markiert. In beiden wird standardmäßig der DSCP-Wert 46/EF verwendet.

ptp clock ordinary domain 0

servo tracking-type R-DTI

clock-port TOMASTER slave

announce interval -3

announce timeout 10

delay-req interval -4                                 <<< RECOMMENDED VALUE

sync interval -4                                      <<< RECOMMENDED VALUE

transport ipv4 unicast interface Lo1588 negotiation   <<< IPV4 UNICAST PACKETS SOURCED FROM THE LO1588 interface

clock source 15.88.15.88                              <<< THIS IS YOUR PTP MASTER

clock source 15.88.2.8 1                              <<< THIS IS THE ALTERNATE MASTER FOR PTP REDUNDANCY (OPTIONAL)

In diesem Beispiel ist der Uhrenport so konfiguriert, dass er das Standard-PTP-Profil verwendet. Die Konfiguration des G.8275.2-Profils finden Sie im Abschnitt: Das G.8275.2-Profil.

Hinweis: Der empfohlene Wert für Synchronisierungs- und Verzögerungsintervall beträgt -4 (16 pps) oder -5 (32 pps). Es wird empfohlen, keine Werte größer als -4 (-3,..) zu verwenden. Die Ankündigungsintervalle können auf ein beliebiges Intervall festgelegt werden, das kleiner oder gleich 0 (0,-1,-2,-3) ist.

Bei der PTP-Redundanzkonfiguration können die cBR-8-Switches bei einem nicht erreichbaren Master an die alternative Quelle weitergeleitet werden. Sobald der Master wieder verfügbar ist, kehrt cBR-8 zur Master-Quelle zurück.

Überprüfung

Überprüfen Sie mit diesem Befehl, ob der Status PHASE_ALIGNED lautet und die Anzahl der gesendeten und empfangenen Pakete erhöht ist:

cBR-8#show ptp clock running domain 0

PTP Ordinary Clock [Domain 0]

State          Ports     Pkts sent   Pkts rcvd   Redundancy Mode

PHASE_ALIGNED  1         462249      1104590     Hot standby

PORT SUMMARY

PTP Master

Name      Tx Mode    Role    Transport   State    Sessions     Port Addr

TOMASTER  unicast    slave   Lo1588      Slave    1            15.88.15.88

SESSION INFORMATION

TOMASTER [Lo1588] [Sessions 1]

Peer addr     Pkts in    Pkts out  In Errs  Out Errs

15.88.15.88   1104590    462249    0        0

Einschränkungen

- Derzeit unterstützt cBR-8 kein PTP über MPLS. Wenn die PTP-Pakete also mit MPLS-Tags versehen sind, wird die Uhr nicht synchronisiert. Es besteht eine Verbesserungsanfrage, dass diese Funktion unterstützt wird. Sie können die folgenden Aktualisierungen möglicherweise über den folgenden Link durchführen: CSCvj02809.

- Als PTP-Profil können Sie entweder das Standardprofil verwenden (wie bisher) oder das G.8275.2-Profil angeben (empfohlen), wie im nächsten Abschnitt beschrieben. Beachten Sie, dass selbst wenn IOS-XE die Konfiguration des G.8265.1-Profils ermöglicht, dies in der DOCSIS-Umgebung mit cBR-8 und RPD nicht unterstützt wird.

Das G.8275.2-Profil

Sie können das G.8275.2-Profil auf dem cBR-8-Slave mit einer GM-Quelle konfigurieren:

ptp clock ordinary domain 44

servo tracking-type R-DTI

clock-port TOMASTER slave profile g8275.2   <<<<<<<<<<

announce interval -3

announce timeout 10

delay-req interval -4

sync interval -4

transport ipv4 unicast interface Lo1588 negotiation

clock source 15.88.15.88

Hinweis: Wenn die PTP-Quelle nicht direkt verbunden ist und mehr als ein Hop dazwischen liegt, wird empfohlen, das G.8275.2-Profil zu verwenden.

Wie bereits in diesem Artikel erwähnt, wird die PTP-Grenze auf cBR-8 noch nicht unterstützt. Wenn Sie jedoch das G.8275.2-Profil auf dem cBR-8-Slave mit zwei GM-Quellen konfigurieren möchten, müssen Sie die Randdomänendefinition auf diese Weise verwenden:

ptp clock boundary domain 44

servo tracking-type R-DTI

clock-port slave1 profile g8275.2

<...>

transport ipv4 unicast interface Lo1588 negotiation

clock source 15.88.15.88        <<< THIS IS YOUR PTP MASTER

clock-port slave2 profile g8275.2

<...>

transport ipv4 unicast interface Lo1588 negotiation

clock source 15.88.2.8          <<< THIS IS THE ALTERNATE MASTER FOR PTP REDUNDANCY

Hinweis: Trotz des Boundary Schlüsselworts funktioniert der cBR-8 wie eine normale Uhr. Diese Grenzwertkonfiguration muss und kann nur in diesem speziellen Fall verwendet werden: redundante PTP-Konfiguration mit 2 GMs unter Verwendung des Profils g8275.2 auf dem cBR-8-Slave.

Slave-Uhr auf RPD

Trotzdem muss die RPD-Konfiguration in cBR-8 selbst eingegeben werden, da cBR-8 das Remote Phy-Gerät bereitstellt.

ptp r-dti 1

[profile G.8275.2]                    <-- ONLY IF SPECIFIED IN THE cBR-8 PTP CONFIGURATION

ptp-domain 0

clock-port 1

clock source ip 15.88.15.88           <-- THIS IS YOUR PTP MASTER

clock source ip 15.88.2.8 alternate   <-- THIS IS THE ALTERNATE MASTER FOR PTP REDUNDANCY (OPTIONAL)

sync interval -4

announce interval -3

Vorsicht: Die ptp-Domänennummer muss mit der auf dem PTP-Master konfigurierten Nummer übereinstimmen.

Vorsicht: Wenn der Befehl ethernet <index> nicht unter clock-port <number> konfiguriert ist, entspricht der Standard-Ethernet-Index der konfigurierten Uhrzeit-Port-Nummer. Dies entspricht den physischen Ports auf der RPD (Ethernet 1 entspricht vbh0, Ethernet 2 zu vbh1). Wenn diese Konfiguration nicht mit dem physischen Port übereinstimmt, der auf der RPD verwendet wird, wird keine Synchronisierung mit der Uhr durchgeführt.

Hinweis: Die Intervalle für Synchronisierung und Ankündigung werden in der Log2-Skalierung angegeben.

Value Log calculation Value in seconds

-5   2^-5        1/32s

-4   2^-4        1/16s

-3   2^-3        1/8s

-2   2^-2        1/4s

-1   2ˆ-1        1/2s

0    2^0         1s

1    2^1         2s

2    2^2         4s

3    2^3         8s

4    2^4         16s

5    2^5         32s

Überprüfung

Diese Befehle, die von der RPD-Konsole ausgegeben werden, können verwendet werden, um den PTP-Status zu überprüfen, der in PHASE_LOCK und SUB_SYNC enthalten sein muss, sowie die Synchronisierungs-, Verzögerungs- und Verzögerungsantwortindikatoren, die erhöht werden müssen:

# ssh 10.6.17.9 -l admin

R-PHY>ena

R-PHY#show ptp clock 0 state

apr state : PHASE_LOCK       <<<

clock state : SUB_SYNC       <<<

current tod : 1506419132 Tue Sep 26 09:45:32 2017

active stream : 0

==stream 0 :

port id : 0

master ip : 15.88.15.88

stream state : PHASE_LOCK    <<< Stream state must be PHASE_LOCK

Master offset : 1212         <<< Master offset (in ns) must be as close to 0 as possible

Path delay : -81553

Forward delay : -80341       <<< Forward delay and reverse delay must be within 500us of each other

Reverse delay : -77791       <<< Forward delay and reverse delay must be within 500us of each other

Freq offset : -86279

1Hz offset : -615

R-PHY#show ptp clock 0 statistics

<output omitted>

streamId  msgType           rx          rxProcessed     lost        tx

0        SYNC              8585001     8584995         0           0          <<<<<<

0        DELAY REQUEST     0           0               0           8585000    <<<<<<

0        P-DELAY REQUEST   0           0               0           0

0        P-DELAY RESPONSE  0           0               0           0

0        FOLLOW UP         0           0               0           0

0        DELAY RESPONSE    8584998     8584998         5           0          <<<<<<

0        P-DELAY FOLLOWUP  0           0               0           0

0        ANNOUNCE          536571      536571          0           0

0        SIGNALING         5593        5593            0           5591

0        MANAGEMENT        0           0               0           0

TOTAL                    17712163    17712157        5           8590591

Hinweis: PHASE_LOCK ist der korrekte Status, wenn alles funktioniert. Weitere Zustände und deren Definition finden Sie im Abschnitt Uhrzustand.

Warnung: Es gab Probleme mit der Uhrenstabilität auf den RPDs, bei denen sich die Netzwerkverzögerung zwischen dem PTP-Master und dem RPD (Änderungen über 5 ms) stark änderte. Die RPD-Funktion kann auf das Freerun-Timing zurückfallen, wodurch mehrere Probleme wie Modems offline gehen können. RPD veröffentlicht Version 6.7 und höher, filtert große Jitter-Pakete und passt den Verzögerungsschwellenwert an, um die PTP-Stabilität zu verbessern.

Grenzuhr auf ASR900

Angenommen, Sie möchten eine Grenzwertuhr als alternativen Master für cBR-8 und RPD konfigurieren, falls die Referenzuhr ausfällt oder nicht erreichbar ist. Diese Grenzwertuhr verwendet aus Redundanzgründen eine andere Masterquelle (in diesem Beispiel 15.88.200.8). Die Konfiguration der Referenzuhr in diesem Szenario unterscheidet sich nicht von der zuvor beschriebenen, wird daher in diesem Abschnitt ausgelassen.

ptp clock boundary domain 0

clock-port TO-MASTER slave

sync interval -5

transport ipv4 unicast interface Lo2008 negotiation

clock source 15.88.200.8      <<< THE PTP MASTER (Different from PTP master described above)

clock source 15.88.20.8 1     <<< AN ALTERNATE MASTER USED FOR REDUNDANCY (OPTIONAL)

clock-port TO-SLAVE master

transport ipv4 unicast interface Lo1588 negotiation

interface Loopback1588

ip address 15.88.2.9 255.255.255.255

end

Überwachen mit SNMP

Um die Anzahl der ptp-Sitzungen auf dem ASR900 und cBR-8 mit SNMP zu überwachen, können Sie Folgendes verwenden:

Object - cPtpClockPortNumOfAssociatedPorts

OID - 1.3.6.1.4.1.9.9.760.1.2.7.1.10

Fehlerbehebung

Dieser Abschnitt enthält Informationen, die Sie zur Fehlerbehebung in Ihrer Konfiguration verwenden können.

Fehlerbehebung beim PTP-Master (ASR900)

Auf dem Master ist es am wichtigsten, sicherzustellen, dass PTP eine Netzwerkuhr-Quelle für die Taktgebung hat, entweder eine GPS-Antenne (bevorzugt) oder einen lokalen Oszillator.

Um sicherzustellen, dass die Netzwerkuhr wie erwartet funktioniert, können Sie den folgenden Befehl verwenden:

ASR900#show network-clocks synchronization

Symbols: En - Enable, Dis - Disable, Adis - Admin Disable

NA - Not Applicable

* - Synchronization source selected

# - Synchronization source force selected

& - Synchronization source manually switched

Automatic selection process : Enable

Equipment Clock : 2048 (EEC-Option1)

Clock Mode : QL-Enable

ESMC : Enabled

SSM Option : 1

T0 : Internal

Hold-off (global) : 300 ms

Wait-to-restore (global) : 300 sec

Tsm Delay : 180 ms

Revertive : No

Nominated Interfaces

Interface SigType Mode/QL Prio QL_IN ESMC Tx ESMC Rx

*Internal NA NA/Dis 251 QL-SEC NA NA   <<<<<

External R0 10M NA/Dis 1 QL-FAILED NA NA

Gi0/2/5 NA Sync/En 1 QL-FAILED QL-PRC -

Fehlerbehebung beim PTP-Slave (cBR-8)

Auf der cBR-8 als Slave ist zu beachten, dass die Schnittstelle nur die SUP-DPIC-Schnittstellen unterstützt, um (ab jetzt) eine Verbindung zum PTP-Master herzustellen. Daher wird die Gig0-Schnittstelle oder die RPHY PIC-Schnittstellen nicht verwendet, da PTP möglicherweise nicht über diese Schnittstellen funktioniert.

Hinweis: Weitere Informationen finden Sie im Cisco Remote PHY Device Software Configuration Guide.

Während der ersten PTP-Aushandlung kann es bis zu 35 Minuten dauern, bis der cBR-8 seine Uhr an der Uhr des PTP-Masters anpasst und ausrichtet. Während dieser Zeit wird die Uhr auf cBR-8 im AKQUIRING-Status angezeigt:

cBR-8#show ptp clock running

PTP Ordinary Clock [Domain 0]

State      Ports     Pkts sent     Pkts rcvd     Redundancy Mode

ACQUIRING  1         687           1995          Hot standby

PORT SUMMARY

PTP Master

Name       Tx Mode     Role     Transport    State           Sessions   Port Addr

TOMASTER   unicast     slave    Lo1588       Uncalibrated    1          15.88.15.88

Wenn der ACQUIRING-Status länger als 35 Minuten dort bleibt, kann dies darauf hindeuten, dass die PTP-Referenzuhr nicht sehr genau ist und sich hin und her bewegt, wodurch der cBR nicht in der Lage ist, die CQUIRE-Nummer richtig zu erfassen. Dies kann beispielsweise bei einem Linux-Server mit PTPd auftreten.

Die PTP-Uhr sowohl auf dem cBR-8 als auch auf dem RPD muss vor der Behebung von DOCSIS-Problemen eine Phasensynchronisierung mit dem Master durchführen. Es gibt eine Reihe von Befehlen, die diesen Zustand zusammen mit der Anzahl der Pakete anzeigen können. In dieser Ausgabe soll die Paketinkrementierung für die Synchronisierung, die Verzögerungsanforderung und die Verzögerungsantwort angezeigt werden:

cBR-8#show platform software ptpd stat stream 0

LOCK STATUS : PHASE LOCKED                          <<<<<<< must be PHASE LOCKED

SYNC Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : -5, Acting Interval -5

Tx packets : 0,  Rx Packets : 24074045            <<<<<<< Rx Packets must increase

Last Seq Number : 42454,  Error Packets : 0       <<<<<<< Last Seq Number must increase

Delay Req Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval : -5

Tx packets : 24077289, Rx Packets : 0             <<<<<<< Tx Packets must increase

Last Seq Number : 0, Error Packets : 0

Delay Response Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : -5, Acting Interval : -5

Tx packets : 0, Rx Packets : 23983049             <<<<<<< Rx Packets must increase

Last Seq Number : 31420, Error Packets : 0        <<<<<<< Last Seq Number must increase

Announce Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : -3, Acting Interval : -3

Tx packets : 0, Rx Packets :  6030915             <<<<<<< Rx Packets must increase

Last Seq Number 44276 Error Packets 0             <<<<<<< Last Seq Number must increase

Signalling Packet Stats

Time elapsed since last packet: 0.0

Configured Interval : 0, Acting Interval : 0

Tx packets : 9944, Rx Packets : 9521              <<<<<<< Tx Packets and Rx Packets must increase

Last Seq Number : 0, Error Packets : 0

<output omitted>

Die Streamnummer kann unter dem bereits eingeführten Befehl show ptp clock running domain 0 im Abschnitt SESSION INFORMATION überprüft werden. Die erste aufgeführte Sitzung ist Stream 0, die zweite Stream 1 usw.

Wenn einige der Zähler nicht ansteigen, besteht die Möglichkeit eines Netzwerkproblems. Es wird empfohlen, den Paketverlust zu überprüfen.

DTI und PTP

Um PTP auf dem cBR-8 zu konfigurieren, muss die DTI-Kabeluhr deaktiviert sein. Andernfalls wird folgende Meldung angezeigt:

%[PTP]: NetSync source already configured. PTP slave configuration not allowed.

Auch wenn die I-CMTS-Linecard schließlich im selben Chassis eingesetzt wird, ist PTP-Taktgebung erforderlich. Daher kann ein potenzieller Ausfall der PTP GM-Uhr auch die Modems hinter einer I-CMTS-Linecard beeinträchtigen.

Uhrzeitverzögerungen und Offset

Um den Offset von der Referenzuhr zu überprüfen und zu erfahren, welche Verzögerungen beim Weiterleitungspfad zum Master und im umgekehrten Pfad auftreten, können Sie diesen Befehl verwenden, der zuvor eingeführt wurde, und durch den Abschnitt Aktuelles Datensatz filtern.

Der Offset-Wert vom Master muss so nahe wie möglich bei 0 liegen, und die Verzögerung des Weiterleitungspfads muss der Verzögerung des umgekehrten Pfads so weit wie möglich entsprechen.

Im folgenden Beispiel werden gute Werte verglichen mit schlechten Werten, die während einer problematischen Bedingung erfasst wurden:

----------------- GOOD -----------------

cBR-8#show platform software ptpd stat stream 0 | s Current Data Set

Current Data Set

Offset from master : -0.000000313

Mean Path Delay    : +0.000025042

Forward Path Delay : +0.000024729

Reverse Path Delay : +0.000024660

--------------- NOT GOOD ---------------

cBR-8#show platform software ptpd stat stream 0 | s Current Data Set

Current Data Set

Offset from master :  +0.002812485

Mean Path Delay    :  +0.000022503

Forward Path Delay :  +0.002834302

Reverse Path Delay :  -0.002789295

Die Werte werden in Sekunden ausgedrückt (daher ist die niedrigste signifikante Ziffer, die rechte Ziffer, Nanosekunde), und der Offset vom Master wird als mittlere Pfadverzögerung abzüglich der Verzögerung des Weiterleitungspfads berechnet.

Die mittlere Pfadverzögerung wird als Durchschnitt zwischen Vor- und Rückwärts berechnet: (Verzögerung für den Vorwärtsweg + Verzögerung für den umgekehrten Pfad) / 2.

In der idealen Welt wäre der Ausgleich vom Master 0, da die Verzögerung des Weiterleitungspfads der Verzögerung des umgekehrten Pfads entspricht, wodurch beide gleich der mittleren Pfadverzögerung sind.

Abhängig von der Asymmetrie zwischen dem Vorwärtspfad und dem Rückwärtspfad kann ein negativer Offset vom Master (wenn die Verzögerung des umgekehrten Pfads größer als die Verzögerung des Vorwärtspfads ist) oder ein positiver Offset (wenn die Verzögerung des umgekehrten Pfads kleiner als die Verzögerung des Vorwärtspfads ist) vorhanden sein.

Wenn der Offset-Wert zu groß ist oder man sehr schwankende Werte beobachtet, ist dies möglicherweise ein Jitter-Problem oder eine nicht genaue Referenzuhr.

Je höher der Jitter, desto länger dauert die RPD oder cBR-8 in den PHASE_ALIGNED-Zustand, und desto länger dauert es, sich von einer HOLDOVER-Situation zu erholen.

Mehrere Pfadkonfigurationen wirken sich stark auf Jitter aus (da einige Pakete Pfad A verwenden und einige Pakete Pfad B mit unterschiedlichen Verzögerungen verwenden, was für cBR-8 und RPD als Jitter gilt). Daher muss der PTP-Datenverkehr einen Pfad verwenden (kein Load Balancing zwischen mehreren Verbindungen).

Fehlerbehebung beim PTP-Slave (RPD)

Auf der RPD-Seite finden Sie alle interessanten Befehle unter dem Schirm show ptp:

R-PHY#show ptp clock 0 state

apr state : PHASE_LOCK

clock state : SUB_SYNC

current tod : 1506426304 Tue Sep 26 11:45:04 2017

active stream : 0

==stream 0 :

port id : 0

master ip : 15.88.15.88

stream state : PHASE_LOCK

Master offset : 6010

Path delay : -78442

Forward delay : -72432

Reverse delay : -81353

Freq offset : -86206

1Hz offset : -830

R-PHY#show ptp clock 0 statistics

AprState 6 :

2@0-00:14:54.347 3@0-00:14:15.945 2@0-00:06:24.766

1@0-00:06:15.128 0@0-00:03:59.982 4@0-00:03:40.782

ClockState 5 :

5@0-00:06:49.252 4@0-00:06:46.863 3@0-00:06:43.016

2@0-00:06:25.017 1@0-00:06:24.728

BstPktStrm 3 :

0@0-00:14:45.560 4294967295@0-00:14:07.272 0@0-00:06:15.160

StepTime 1 :

406874666@0-00:05:46.080

AdjustTime 99 :

427@0-02:05:11.705 -414@0-02:04:10.705 -396@0-02:03:09.705

145@0-02:02:08.705 -157@0-02:00:06.705 327@0-01:58:04.705

-195@0-01:57:03.705 -46@0-01:56:02.705 744@0-01:55:01.705

streamId msgType rx rxProcessed lost tx

0 SYNC 246417 246417 4294770689 0

0 DELAY REQUEST 0 0 0 118272

0 P-DELAY REQUEST 0 0 0 0

0 P-DELAY RESPONSE 0 0 0 0

0 FOLLOW UP 0 0 0 0

0 DELAY RESPONSE 117165 117165 4294902867 0

0 P-DELAY FOLLOWUP 0 0 0 0

0 ANNOUNCE 82185 82184 4294901761 0

0 SIGNALING 78 78 0 78

0 MANAGEMENT 0 0 0 0

TOTAL 445845 445844 12884575317 118350

R-PHY#show ptp clock 0 config

Domain/Mode : 0/OC_SLAVE

Priority 1/2/local : 128/255/128

Profile : 001b19000100-000000 E2E

Total Ports/Streams : 1 /1

--PTP Port 1, Enet Port 1 ----

Port local Address :10.6.17.9

Unicast Duration :300 Sync Interval : -5

Announce Interval : -3 Timeout : 11

Delay-Req Intreval : -4 Pdelay-req : -4

Priority local :128 COS: 6 DSCP: 47

==Stream 0 : Port 1 Master IP: 15.88.15.88

Hinweis: Weitere Schritte zur Fehlerbehebung bei RPD-Vorgängen finden Sie im Artikel RPD DOCSIS Throughput Performance Issues (Fehlerbehebung bei RPD DOCSIS-Durchsatzleistungsproblemen).

Zugehörige Informationen

- Precision Time Protocol - Wikipedia

- 1588-2008 - IEEE-Standard für ein Precision Clock Synchronization Protocol for Networked Measurement and Control Systems

- G.8265.1: Precision Time Protocol Telecom-Profil für die Frequenzsynchronisierung

- G.8275.1 : Precision Time Protocol Telecom-Profil für Phase-/Zeitsynchronisierung mit vollständiger Timing-Unterstützung durch das Netzwerk

- G.8275.2 : Precision Time Protocol Telecom-Profil für die Zeitsynchronisierung mit partieller Timing-Unterstützung aus dem Netzwerk

- Konfigurationsleitfaden für Timing und Synchronisierung, Cisco IOS XE Everest 16.5.1 (Cisco ASR Serie 900)

- Cisco Remote PHY Device Software Configuration Guide Cisco 1x2 RPD Software 1.1

- Fehlerbehebung bei RPD DOCSIS-Durchsatzproblemen