PTP - Precision Time Protocol

Wussten Sie, dass es Windows 10/11/2019 neben NTP auch das genauere PTP nutzen kann? Auslöser für diese Seite war allerdings eine Analyse zu DECT-VoIP-Geräten, die PTP nutzen können und was man dabei beachten muss.

Diese Seite ist nicht für den normalen AD-Admin relevant. Für eine korrekte Zeit ist eine passende NTP-Konfiguration ausreichend. (Siehe Zeitsynchronisation in Netzwerken). PTP ist für Spezialfälle mit deutlich weniger Abweichung zwischen Systemen im Bereich von μs oder gar ns (Nanosekunden).

Zeit im Netzwerk

Eine synchrone Uhrzeit auf allen Netzwerkgeräten ist eine absolut notwendige Aufgabe und Windows Administratoren machen sich darüber weniger Gedanken, da Microsoft in Windows schon alle Default-Einstellungen so konfiguriert hat, dass es meist ganz gut funktioniert. Sie müssen nur die Uhrzeit ihres DCs, der auch die PDC-Emulator-FSMO-Rolle hat, richtig setzen und alle Domainmitglieder bekommen die aktuelle Uhrzeit per NTP. (Siehe auch Zeitsynchronisation in Netzwerken) Alleinstehende Windows Computer zuhause nutzen die öffentlichen NTP-Server von Microsoft. Probleme machen manchmal virtuelle Maschinen, denn sie die Uhrzeit von einem Host über die VM-Erweiterungen bekommen statt NTP zu nutzen, da ESX-Hosts und auch viele HyperV-Hosts nicht in die Domäne eingebunden sind und die manuelle Konfiguration von NTP gerne mal vergessen wird.

Ohne korrekte Zeit geht aber nicht nur die Uhrzeit-Anzeige auf dem Desktop falsch. Kerberos-Tickets haben nur eine begrenzte Gültigkeit und es fällt auf, wenn der Client noch ein abgelaufenes Ticket verwendet, weil er in der Vergangenheit lebt. Gleiches gilt für die Nutzung von Cloud-Diensten mit SAML-Tokens, die auch einen Gültigkeitszeitraum haben. Seltener sind große Abweichungen von Tagen, Monaten oder Jahren, so dass TLS-Handshakes mit Zertifikaten fehlschlagen. Bei all diesen Nutzungen sind aber einige Sekunden Abweichung durchaus unkritisch.

Interessanter wird es aus Sicht der Security, wenn Sie Events verschiedener Server zusammenführen wollen. Dann sollten alle Systeme schon eine möglichst übereinstimmende Zeit haben. Wobei wir uns hier schon im Bereich von unter einer Sekunde bewegen. Mittels NTP ist es meist kein Problem, eine Genauigkeit auf wenige Millisekunden zu erreichen. Eine Anfrage nach der aktuellen Uhrzeit per 123/UDP dauert meist wenige Millisekunden und selbst über das Internet unter Nutzung eines "falschen " NTP-Server aus einem anderen Kontinent liefert mit einer RoundTrip-Time von meist unter 200ms immer noch eine halbwegs genaue Zeit. Der Client misst die RoundTripTime und addiert die Hälfte davon auf die erhaltene Zeit.

Der Client starte eine Anfrage an den konfigurierten NTP-Server zum Zeitpunkt t1 und misst die Zeit bis zur Antwort. Der NTP-Server bekommt die Anfrage aufgrund der Laufzeit bei t2 und antwortet mit seiner Zeit etwas später (t3). Die Antwort des NTP-Server mit der Zeit kommt mit Verzögerung beim Client an. Der Client nimmt nun die gemeldete Zeit und wenn Hin- und Rückweg gleich lange gedauert haben, kann er die gemessene Latenzzeit halbieren und auf die gemeldet Zeit addieren. Die Abweichung wäre dann maximal die halbe Latenzzeit. Problematisch könnten nur sehr alte asynchrone Verbindungen, z.B. DSL16 sein, bei denen der langsame Uplink etwas längere Zeiten verursacht.

Allerdings setzt der NTP-Client nun nicht einfach die Zeit, denn Zeit muss immer vorwärts laufen. Sprünge sind nicht gewünscht. Daher lässt der NTP-Client seine Systemzeit entsprechend "langsamer" oder schneller laufen, bis die Abweichung weg ist. Bei Windows können Sie diese "Drifts" oder das "Wischen" sogar konfigurieren und wenn die Zeit zu stark abweicht, dann setzt Windows die Zeit einfach ohne Rücksicht. Er wird auch nicht jede Sekunde per NTP immer wieder neu fragen, sondern kann die gemeldete Zeit in seine eigene "Quarzuhr" übernehmen und dann einige Stunden mit der lokalen Uhr weiter arbeiten. All diese Zeiten sind in Grenzen "dynamisch". Damit erklärt sich auch, dass nach einiger Zeit alle System im Netzwerk eine halbwegs korrekte aber nie die gleiche Zeit haben. Jeder Client fragt selbst.

Es gibt aber auch Dienste, die eine besonders genaue Zeit benötigen aber keinen Zugriff auf das Signal einer Atomuhr oder eines GPS-Empfängers haben oder die Kosten oder Energiebedarf zu teuer ist. Dazu zählen z.B. DECT-Basisstationen, die im Frequenzhopping zwischen den verfügbaren Bändern wechseln und dies mit den anderen DECT-Basen in direkter Nachbarschaft abgestimmt sein muss. Bei Firmen gibt es häufig eine recht dichte Abdeckung mit mehreren Sendern, die sich überlappen. Zwei Sender auf der gleichen Frequenz wäre kontraproduktiv. DECT-Basen könnten natürlich einfach ihre Funkmodule nutzen, um darüber auch ein Zeitsignal auszusenden. Mit PTP gibt es aber ein zu NTP alternatives Protokoll, welches über Netzwerke eine deutlich bessere Zeitabstimmung erlaubt. Ein andere Anwendungsfall sind z.B. Finanzanwendungen und Börsenhandel, wo Zeit sprichwörtlich Geld ist. PTP kommt auch in der Prozessautomatisierung zum Einsatz, wenn Steuerungssysteme eine möglichst synchrone Zeit benötigen.

NTP vs. PTP

Die Genauigkeit von NTP bewegt sich im Bereich von Millisekunden aber das ist für gewisse Prozess immer noch nicht genau genug. Und hier kommt PTP ins Spielfeld. Stellen sie sich vor, es gibt einen Zeit-Master und der sendet seine aktuelle Zeit einfach per Multicast in das Netzwerk. Das Paket kommt beim Switch an und dieser verteilt es nahezu gleichzeitig an alle Ports, die sich über IGMP für den Empfang gemeldet haben. Auf dem Bild sind dies die roten "SYNC"-Messages vom PTP Clock Master, die bei allen drei Clients unterschiedlich schnell ankommen. Die Aktion geht also vom PTP-Server und nicht vom Client aus.

Alle Clients senden dann aber ebenfalls als Multicast eine "Delay_Req"-Meldung ins Netzwerk. Sie fragen damit quasi den Server an, wie sie ihre Zeit anpassen sollen. Der Server kann dann pro Client bestimmen, welche Empfehlung (Delay_Resp = Delay_Response) er als Unicast an den jeweiligen Client sendet oder auch nichts sendet.

Das Sync-Paket kommt auch nicht nur einmal pro Stunde sondern kann deutlich häufiger und regelmäßig kommen. In meinem Mitschnitten habe ich 200ms als Abstand gesehen. Je nach Version sind 1ms-1s wohl üblich.

 Es ist auf jeden Fall deutlich häufiger, als ein NTP-Client auch nur ansatzweise fragen würde. Wir haben also einen Art "Herzschlag" im Netzwerk, einen Leuchtturm, der zyklisch immer die aktuelle Zeit liefert und Clients, die sehr viel genauer die gleiche Zeitbasis nutzen. Sie sieht so ein Roundtrip in einem Netzwerk mit einem Master und vier Clients aus.

Im Paket 111 sendet der aktuelle Master seine Zeit mit einem "Sync Message" an die Multicast-Adresse 224.0.1.129. Kurz darauf fordern die Clients eine "Delay_Req"-Message ebenfalls über einen Multicast an. Der Master weiß ja noch, welche Zeit er gesendet hat und bekommt vom Client die dortige Zeit. damit kann der Master die Abweichung ermitteln und bei Bedarf (Paket 129) eine "Delay_Resp"-Message zurücksenden. Wenn Sie sich ein Paket genauer anschauen, dann würden Sie sehen, dass dazu der Port 319/UDP und 320/UDP genutzt wird.

Wer der Master ist, wird ebenfalls durch den "Best Master Clock (BMC)-Algorithmus" ermittelt. Alle Teilnehmer sind quasi individuelle Uhren, die sich alle auf den gleichen Stand bringen. Der muss allerdings nicht der realen Zeit entsprechen. Daher ist es wichtig, den bestimmenden Server zu kennen. Er wird auch als "Grandmaster Clock" bezeichnet. Oft ist das ein Computer mit einer externen Zeitquelle (NTP, GSM, GPS, DCF77). Die Uhrzeit sollte natürlich stimmen aber für PTP ist es wichtiger, dass alle internen Uhren möglichst synchron laufen. Es gibt sehr viele weitere Quellen, die die genaue Funktionsweise beschreiben, so dass ich dies hier nicht wiedergeben.

PTP extrem

Sie haben nun gelernt, dass PTP anders als NTP funktioniert und der Schwerpunkt neben der korrekten Zeit auch eine möglichst "synchrone" Zeit auf allen Endgeräten ist. Dabei ist aber das Netzwerk und insbesondere die Laufzeit und Jitter eine Herausforderung. PTP kommt im LAN mit den passenden Switches schon auf eine Genauigkeit unter einer Millisekunden in den Beriech von Microsekunden. Aber auch das ist für einige Umgebungen noch nicht "gleich" genug. Denken Sie an physikalische Aufbauten, bei denen die Laufzeit von Schall, Licht, Atome, o.ä. gemessen werden, um Entfernungen zu ermitteln. Die GPS-Empfänger realisieren die Ortung auf wenige Meter oder noch weniger allein anhand er bekannten Position der Satelliten, die eine genaue Uhrzeit senden und aufgrund der unterschiedlichen Laufzeit die Entfernung ermitteln und triangulieren. Das geht auch mit PTP im Netzwerk. Das DFN beschreibt dazu das "White Rabbit"-Verfahren, bei dem eine von allen Teilnehmern empfangbare Frequenz und insbesondere deren Nulldurchgang als Feinjustierung genutzt wird. Damit kommen wir dann in den Nanosekunden-Bereich.

Latenz und Jitter

Wie schon bei NTP ist natürlich die Varianz der Laufzeit ein Faktor, der die Genauigkeit beeinflusst. Wenn das gesendete Paket die Zeit des Absender enthält muss der Empfänger die Laufzeit addieren, um die beim Empfang dann gültige Zeit zu ermitteln. Dazu muss er allerdings die Laufzeit ermitteln. Bei NTP sendet der Client und bekommt eine Antwort und kennt damit die RoundtripTime. Bei PTP startet der Sender und der Empfänge meldet an den Sender zurück und bekommt dann eine Korrektur. Die RundtripTime kann damit eliminiert werden, wenn Sie denn immer identisch ist. Das trifft aber nicht zu, denn je nach Auslastung der Übertragungswege und der Netzwerkkomponenten müssen Pakete auch mal etwas warten. Diese wechselnde Laufzeit wird als Jitter bezeichnet und der sollte möglichst gering sein. So fordert z.B. Spectralink für den Zeitabgleich seiner DECT-Stationen über Netzwerk einen Jitter von <500ns. Sie lesen richtig: Hier steht "Nanosekunden" und nicht etwas "Milli-" oder "Mikro"-Sekunden.


Quelle: Spectralink Synchronization and Deployment Guide https://support.spectralink.com/cms/delivery/media/MCKQMMSJEF2ZAWTPECLHEZJQIKPE

Solche Anforderungen sind natürlich hoch gesteckt und erfordern entsprechende Vorkehrungen.

Spectralink Synchronization and Deployment Guide
https://support.spectralink.com/cms/delivery/media/MCKQMMSJEF2ZAWTPECLHEZJQIKPE

Ein Switch ist langsam

Ich bin sicher, dass alle Leser schon mal einen Switch in der Hand gehabt haben und die grundlegende Funktion kennen. Ein Switch verbindet mehrere Netzwerkgeräte, die z.B. über TwistedPair-Kabel mit 100MBit oder Gigabit angeschlossen sind. Ein eingehendes Paket am Switch landet auf dem Backplane und wird anhand der Ziel-MAC-Adresse zum nächsten Port geleitet oder bei Multicast natürlich an die Ports. Jeder Port hat dann einen Warteschlange, in der die Pakete eingereiht und dann versendet werden. So wird sichergestellt, dass die Pakete vieler Clients an einen Server oder Trunk sich nicht überschneiden. Denn bei aller Geschwindigkeit ist ein Link immer noch eine serielle Verbindung, bei der nicht überholt wird. Nun rechnen wir mal die Durchlaufzeit eines "Store and Foward"-Switch, welcher das Paket empfängt und dann weiterreicht und wieder versendet. Wir betrachten mal eine einfache Überschlagrechnung.  

Ethernet-Paket mit 100 Bytes sind 1000 Bits.
Die DECT-Basis hat einen 100MBit Anschluss
Die reine Übertragungszeit sind 1000 Bits durch 100.000.000 Bits/Sec = 0,00001 Sekunden = 0,01ms = 10µs = 10.000ns

Bei 100MBit benötigt ein 1kBytePaket also ca. 10μs, bis es komplett übertragen ist. Auf der Senderichtung belegt es dann noch einmal 10μs den Link, womit wir die minimale Latenzeit ermitteln können. Eine Gigabit-Verbindung kann nicht nur zehnmal mehr Daten Übertragen, sondern vor allem zehnmal schneller und die Latenzzeit reduziert sich auf bis zu 1μs. Erst mit 10 Gigabit kommen wir auf 100ns Verzögerung aber auch nur, wenn wir keine Jumbo-Pakete o.ä. nutzen. Übrigens: Auch "Hauptspeicher" in ihrem Computer hat eine Latenzzeit, die je nach Modul zwischen 15 und 24ns und die "Systemlatenz" des kompletten Speicherbus auch mal bei 90ns liegen kann.

Latenz ist aber nicht per se ein Problem, sondern wie konstant die Latenz ist. Und da kommt wieder in Spiel, dass Pakete ggfls. warten müssen. Wenn ein 1 Kilobyte-Paket über 100 Megabit gerade übertragen wird und dann ein PTP-Paket durch QoS/DSCP direkt danach dran ist, müsste es dennoch die 10.000ns warten. Selbst bei Gigabit wären es 1000ns und damit doppelt so hoch als die Grenze, die Spektralink bei 500ns zieht. Sie müssten also alle PTP-Pakete auf "unbelasteten" Links übertragen oder bestehende Übertragungen abbrechen, was meines Wissens kein Switch macht. Aber das sind optimale und vereinfachte Werte, denn es gibt weitere Spielverderber:

  • Aktive Übertragung
    Was soll ein Switch denn machen, wenn er gerade ein Daten-Paket mit 1,5kbyte überträgt und dann ein PTP-Paket nachkommt. Er kann das Paket ja schlecht abbrechen. Das PTP-Paket kann zwar durch QoS und DSCP vorgezogen werden aber wird dennoch erst nach der aktiven Übertragung gesendet. Schon haben wir bei Gigabit mal eben 1000ns Jitter drauf addiert bekommen.
  • Jumbo Paket
    Bei iSCSI wird gerne die MTU-Size von 1541 Bytes auf 4k oder noch mehr angehoben. Das ist gut für große Datenpakete, die am Stück mit weniger Overhead z.B. Festplattensektoren übertragen können. Aber PTP wartet dann noch länger
  • " Green Ethernet"
    Energiesparen ist wichtig und wer kennt nicht die Funktion, die LinkSpeed von 1GBit auf 100MBit/100MBit zu reduzieren, wenn keine Pakete anstehen. Kommt dann ein Paket, sendet der Switch das aber dann auch erst einmal mit 100Mbit und wenn mehr Pakete anstehen, dann schaltet er wieder auf 1GBit hoch, was aber auch etwas Zeit braucht. Manchmal sammelt so ein Switch auch Pakete, damit sich das Senden "lohnt". Das ist alles Gift für eine "gleichmäßige Qualität der Latenzzeit", die für Dienste erforderlich sein kann, die auf PTP aufsetzen.
  • QoS ist kein DSCP
    Wer über "Priorisierung" nachdenkt, meint damit die Kennzeichnung von IP-Paket mit QoS. Das gilt aber nur innerhalb des IP-Netzwerks und VLANs. Wenn nun mehrere VLANs auf einem Anschluss konfiguriert sind, dann soll es Switches geben, die das QoS-Tagging von IP nicht auf das VLAN umsetzen. Eine Priorisierung auf Ethernet-Level mit DSCP funktioniert oft auch nur im VLAN und nicht über die Grenzen hinweg.
  • Trunk mit VLANs
    Die Verbindung zwischen Switches wird durch Trunks hergestellt, auf denen mehrere VLANs "tagged" übertragen werden. Wie hier genau ein Switch die unterschiedlichen QoS/DSCP-Prioritäten berücksichtig ist oft nicht deutlich. Dann wartet ihr PTP-Paket am Trunk, bis sein VLAN dran ist.
  • Client-Einflüsse
    Auf dem Client gibt es dann den Netzwerkkartentreiber, PCI-Bus mit DMA, Firewalls etc., die ebenfalls unterschiedliche Zeit zur Verarbeitung brauchen.

All das sind mögliche Ursachen, dass die Latenzzeit von Paketen nicht gleichmäßig ist, sondern abhängig von der Belastung variiert. Der Jitter nimmt dabei zu und sie erreichen mit PTP nicht die gewünschte oder sogar geforderten Genauigkeit. Denken Sie dabei immer daran, dass die Latenzeit nicht das Problem ist, solange sie konstant gleich lang ist.

Nun steht in der Definition von PTP allerdings, dass es durchaus erlaubt ist, bis zu drei Switche zu kaskadieren. Das ist in Gebäuden auch schnell erreicht, wenn ein Gerät auf einer Etage über den Etagenswitch und einem Core-Switch für das Gebäude zu einem Etagenswitch in eine, anderen Stockwerk verbunden ist. Damit haben wir zwei Links, zwei Trunks und drei Switche zu betrachten. PTP kann auch in der Umgebung funktionieren, wenn wir die Umgebung auf PTO optimieren. Dazu gibt es unterschiedliche Ansätze, die irgendwie alle zur Optimierung beitragen können, z.B.:

  • Schneller ist besser z.B. 10+ GBit
    Pakete müssen kürzer warten, wenn die Verbindung schneller ist. Mittlerweile (2024) gehört 10 Gigabit schon fast zum guten Ton im Backend und ein Trunk aus mehreren parallelen Leitungen kann auch mehrere Pakete parallel übertragen.
  • VLAN-Priorisierung oder eigene Trunks für PTP
    Denken Sie darüber nach, vielleicht eine eigene Trunk-Verbindung nur das VLAN mit den kritischen Geräten zu schalten, die PTP nutzen. Prüfen sie auch, ob sie auf einem Trunk mit mehreren VLANs das VLAN mit PTP-Verkehr priorisieren können.
  • Eigene Switche
    Switches sind nicht mehr so teuer und vielleicht sollten Sie Netzwerkverkehre von zeitkritischer Produktion zu normalen Netzwerken durch eigene Switches separieren, wenn ein VLAN mit Priorisierung nicht funktioniert.
  • QoS/DSCP Priorisierung
    Auch wenn Priorisierung nicht das Allheilmittel ist, so ist es doch eine Möglichkeit die PTP-Pakete möglichst gleichmäßig und mit wenig Jitter zu übertragen, wenn Sie nicht länger als ein angefangenes Paket warten müssen. Die VoIP-Administratoren kennen das schon von Skype for Business, Lync und Teams, wo Audio-Pakete gerne mit dem DSCP-Tag "46-EF" (Expedite Forwarding) versehen wurden. Wobei QoS auf IP-Level (OSI-Layer 3) für einen reinrassigen Layer-2-Switch keine Bedeutung hat. Da muss es DSCP sein. Netzwerk und QoS. Die ganze Priorisierung mildert aber nur die Folgen, wenn Paket schon warten und das ist für PTP immer nachteilig.
  • Switch/Router als PTP-Komponente
    Hierbei ist die Netzwerkkomponente aktiver Part des PTP-Designs und übernimmt die Uhrzeit aus dem Netzwerk als Slave und ist seinerseits ein Master im anderen Netzwerk. So genannte "PTP-Ready"-Switche haben diese Logik dann in Hardware implementiert, damit sie möglichst akkurat und ohne Einfluss der sonstigen Belastung des Switches die Zeit umsetzen können
  • Eigene "PTP-Domains"
    Vielleicht müssen ja auch nicht alle PTP-Clients die gleiche Zeit haben. Sie können durchaus mehrere "Inseln" von PTP-Verbundsystemen aufsetzen. Das ist z.B. ein Ansatz, wenn sie mehrere Standorte haben und immer nur innerhalb des Standorts die Zeit hochsynchron sein muss ein Abgleich der Master per NTP oder externe Quellen ausreicht.
  • PTP Hardware
    Wie akkurat kann eine Zeit sein, wenn eine CPU die Zeit von einer internen Uhr ausliest, ein IP-Paket formt, die lokale Firewall das Paket geprüft hat, dann an einen Netzwerktreiber übergibt, welcher das Paket an den Prozessor der Netzwerkkarte weiterreicht und letztlich nach dem Ende des vorherigen Pakets versendet? Wie wäre es, wenn die Netzwerkkarte selbst die Uhrzeit kennt und im Moment des Versands die Zeit in das Paket einfügt und auch beim Empfang dies ermöglicht? Genau das ist heute schon möglich aber muss natürlich von der Hardware, dem Treiber und der Konfiguration unterstützt werden. Die gleiche Optimierung ist natürlich auch auf Switches möglich.

Wie gut ihr PTP-Abgleich ist, kann eigentlich nur eine passende PTP-Software ermitteln. Bei Spectralink sehen Sie den Status in der Verwaltungswebseite, denn alle DECT-Stationen messen den Jitter zur Grandmaster Clock. ein manuelle Vergleich der Zeiten per "NE TIME" o.ä. ist nicht geeignet. Sie können aber mit Wireshark die Pakete mitschneiden und dort die Korrekturen sehen.

Switches mit PTP

An verschiedenen Stellen wird von Switches gesprochen, die PTP nativ unterstützen. Die Weiterleitung eines PTP-Pakets über das Switch Backend und einen Up/Downlink kann je nach Backplane, Belastung und Bandbreite verzögert werden, so dass die Latenzzeiten und insbesondere der Jitter zu hoch wird und damit die Berechnung der Zeit nicht den Anforderungen genügt. Es gibt Switches, die hier entweder eine Priorisierung der PTP-Pakete erlauben. Einige Switches können aber auch selbst eine aktive Rolle spielen. Drei Optionen möchte ich aufführen:

  • "Dumme Switche"
    Sie wissen nicht von PTP und leiten die Pakete einfach als Bridge, eventuell mit DSCP/QoS-Priorisierung weiter. Kann gehen aber ist meist nicht ausreichend.
  • TC = Transparent Clock
    Der Switch "versteht" PTP und sieht das Paket ankommen und ehe er es versendet, weil er, wie lange er dafür gebracht hat. Im PTP-Paket gibt es extra ein Feld für einen "Correction Factor", den der Switch nun mit der vom ihm verursachten Latenzeit addieren. Es versteht sich von selbst, dass der Switch dennoch versucht, diese Zeit zu minimieren. Aber so kann der Empfänger diesen Wert wieder abziehen und damit den Jitter herausrechnen.
  • BC =Boundary Clock
    Hierbei übernimmt der Switch eine aktive Rolle und übernimmt die per PTP synchronisierte Zeit. Er ist eine "Ordinary Clock (OC)" in dem Netz. Wenn er aber nun eine synchrone Zeit hat, kann er auf der anderen Seite sich selbst als Master ausgeben, der eigene "Sync"-Zeitpakete sendet. Die Client (OCs) der anderen Seite übernehmen die Zeit des Switch. Latenzzeiten und Jitter im Switch sind damit eliminiert.

Damit klingt ein Switch mit der Funktion "Boundary Clock" eigentlich als optimale Lösung. Allerdings sind diese Switche deutlich teurer und seltener. Sie kommen eher in industriellen Umgebungen und Forschung zum Einsatz. Sie werden vermutlich nicht alle "Büro-Switche" mit so einer Funktion ausstatten. Damit sind wir dann doch wieder bei separaten Switchen für PTP-Aufgaben.

Wenn ein Switch/Router keine aktive PTP-Unterstützung liefert, dann können sie auf einen Switch mit DSCP und auf einem Router mit QoS die Pakete priorisieren und quasi hoffen, dass die Variabilität in der Verzögerung so ausreichend minimiert wird.

Windows und PTP

Auf der Suche nach PTP-Software habe ich natürlich die ein oder anderen Linux-Module gefunden und war ziemlich überrascht, dass Microsoft die PTP-Funktion sowohl in Windows Server 2019 als auch Windows 10 1809 und neuer schon enthalten ist. Das scheint auch nicht unbedingt "freiwillig" passiert zu sein, denn es gibt wohl Vorgaben in US und der EU:


Quelle: https://techcommunity.microsoft.com/blog/networkingblog/top-10-networking-features-in-windows-server-2019-10-accurate-network-time/339739

Das hat mich dann auch etwas überrascht, denn damit wurde ich bis 2024 noch nicht konfrontiert. Allerdings ist die Funktion auch nicht "per Default" aktiviert. Es gibt auch keine richtige GUI o.ä. dafür, sondern sie müssen den PTP-Provider per Regedit oder ein Powershell Modul und Kommandozeilen aktiveren und Firewall-Regeln einrichten.

New-NetFirewallRule -DisplayName 'PTP-319' -Name 'PTP-319' -LocalPort 319 -Direction Inbound -Action Allow -Protocol UDP
New-NetFirewallRule -DisplayName 'PTP-320' -Name 'PTP-320' -LocalPort 320 -Direction Inbound -Action Allow -Protocol UDP

Dann müssen Sie die Konfiguration noch anpassen, z.B. durch den Import einer REG-Datei

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\PtpClient]
"PtpMasters"="192.168.100.10 192.168.100.11"
"Enabled"=dword:00000001
"InputProvider"=dword:00000001
"DllName"="c:\\windows\\system32\\ptpprov.dll"
"DelayPollInterval"=dword:00003e80
"AnnounceInterval"=dword:00000fa0
"EnableMulticastRX"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider]
"Enabled"=dword:00000000

Oder Kommandozeilen mit REG.EXE oder natürlich Gruppenrichtlinien.

REM Enable PTP with 192.168.100.10 and  192.168.100.11 als PTP Masters

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\PtpClient /t REG_SZ /v PtpMasters /d "192.168.100.10 192.168.100.11" /f
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\PtpClient /t REG_DWORD /v Enabled /d 1 /f
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\PtpClient /t REG_DWORD /v InputProvider /d 1 /f
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\PtpClient /t REG_SZ /v DllName /d "c:\windows\system32\ptpprov.dll" /f
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\PtpClient /t REG_DWORD /v DelayPollInterval /d 0x3e80 /f
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\PtpClient /t REG_DWORD /v AnnounceInterval /d 0x0fa0 /f
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\PtpClient /t REG_DWORD /v EnableMulticastRX /d 0x0 /f

REM Disable other input providers
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient /t REG_DWORD /v Enabled /d 0 /f
reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /t REG_DWORD /v Enabled /d 0 /f

Das Beispiel deaktiviert den NTPClient  und VMICTimeProvider . Zudem wird der PTP-Master statisch vorgegeben. Zudem muss auch noch auf der Netzwerkkarte eine Option gesetzt werden, um die Verzögerungen durch den Kartentreiber zu reduzieren. Wenn ich die Funktion so richtig verstehe, dann ist Windows nur ein PTP-Client, der die Zeit von einem Master bezieht aber selbst keine PTP-Dienst anbietet. Sogar der Empfang per Multicast ist per Default abgeschaltet und müsste durch "EnableMulticastRX =1 " erst aktiviert werden.

Abschalten geht natürlich schnelle, da nur die "Enabled"-Einträge relevant sind:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\PtpClient]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider]
"Enabled"=dword:00000001

Die Ergebnisse finden Sich dann im Eventlog unter "Event Viewer > Applications and Services > Microsoft > Windows > Time-Service-PTP-Provider > PTP-Operational"

Ich habe hier erst einmal nicht weiter geforscht, denn für einen Windows Server und Windows Client ist eine aktuelle Zeit wichtig aber auch mit NTP erreichen wir wenige Millisekunden Genauigkeit.

Wenn ihre Produktionsanlage, DECT-Umgebung oder eine andere Komponenten eine noch genauere Zeitsynchronisation braucht, dann können Sie einen PTP-Referenzserver (Hardware) im Netzwerk bereitstellen und dann natürlich auch ihre Windows Clients davon profitieren lassen. Der PTP-Provider in W32Time ist aber nur Client kann kein Server sein. Microsoft schreibt selbst, dass Sie den Client z.B. gegen PTPD (https://github.com/ptpd/ptpd/commits/master) getestet haben.

Sicherheit

Die ganze Welt redet von TLS 1.2 und höher, OAUTH/SAML-Tokens und Authentifizierung. Wenn wir PTP anschauen, dass ist es wie NTP erst einmal nicht gesondert geschützt. Das Übertragungsprotokoll UDP kennt keinen klassischen Handshake und die Source-IP kann problemlos gefälscht sein. Die übertragenen Daten sind auch nicht wirklich verschlüsselt, denn es ist ja "nur eine aktuelle Zeit" mit wenig Schutzbedarf, die jeder Client empfangen kann, der im Netzwerk ist und per IGMP sich für den Empfang der Multicast-IP-Adressen 224.0.1.129-224.0.1.132 eingetragen hat. So einfach ist es aber nicht, denn es gibt schon Störpotential

  • Flooding
    Ich könnte einfach versuchen die Teile einer Verbindung zu überlasten, indem ich selbst viele große Datenpakete sende. Ein "PING -l1024 <ip des Device>" sendet 1kByte Pakete und auch über Gigabit dauern 10.000 Bit nun mal 10.000  / 1.000.000.000= 1/100.000 = 100μs, die auch ein priorisiertes Paket warten muss. Ich müsste natürlich schon längere Zeit hier eingreifen, denn ein Client übernimmt eine aktualisierte Zeit nicht sofort, sondern gleicht sie langsam an.
  • Spoofing. UDP Source-IP
    Die Quell-IP bei einer UDP-Verbindung ist nicht wie beim TCP-Handshake verifiziert. Theoretisch könnte ich mich auch als TimeServer mit der gleichen IP-Adresse ausgeben und einen "Sync" senden. Ich würde sogar die "Delay_Req"-Messages bekommen, die an die Multicast-Adresse gehen und dann mit einer "Delay_Resp"-Message mit gefälschter IP-Adresse den Client stören. Auch hier müsste ich natürlich gegen den weiter aktiven echten Master anschreien. Mal eben funktioniert das nicht
  • Störpotential: falsche Zeit broadcasten
    Was sollte mich hindern einfach eine ganz andere Zeit zu senden? Sie können das Risiko durch VLANs und Access-Listen auf Ports reduzieren, z.B. dass nur der Master auf Port 319/UDP ein "Sync"- senden darf und die Clients auf 320/UDP antworten können.
  • Best Master Clock (BMC)-Algorithmus stören
    Ich könnte mich in dem Zuge auch als "hochwertige Quelle" mit GPS-Uhr o.ä. ausgeben und im Best Master Clock (BMC)-Algorithmus mich zum Grand Master erklären lassen. Dann bin ich der Chef. Nach einiger Zeit hätten dann alle Client zwar immer noch die gleiche aber halt falsche Zeit.

Ich habe keinen der Szenarien durchprobiert und sicher gibt es noch weitere Möglichkeiten und vielleicht sogar Schutzvorkehrungen, von denen ich noch nicht weiß. Aber ich nehme mit, dass ich per NTP in normalen Netzwerken vermutlich noch besser fahre aber eine Nutzung von PTP entsprechende Schutzmechanismen des Übertragungsnetzwerks einplanen sollte, z.B.:

  • Eigenes VLAN
    Wenn all diese zeitkritischen Endgeräte in einem eigenen VLAN sind, und der Zugang reglementiert wird (802.1x, Portsecurity) und ein Router die Multicast-Pakete nur in diesen Netzwerken weitergibt, dann sollte eine externe Störung nicht möglich sein. Eigene VLANs lassen sich dann auch auf Trunks zwischen den Switches einfach priorisieren und theoretisch sogar eigene Trunks reservieren, um die Latenzzeit und vor allem den Einfluss auf den Jitter zu minimieren.
  • IGMP und Multicast-Zuweisung
    Normalerweise meldet sich ein Client, wenn er Pakete für eine Multicast-IP-Adresse erhalten möchte, per IGMP am Switch/Router. Die Annahme dieser IGMP-Requests kann ich auf Netzwerkebene kontrollieren, so dass auch hier nur die Geräte "teilnehmen" dürfen, die ich explizit dafür zugelassen habe. Oder ich weise die Multicast-Konfiguration direkt statisch zu.
  • Firewall/Router UDP 319/320
    Da PTP über das Protokoll UDP und bekannte Ports arbeitet, kann ich auch auf Routern und Firewalls mit entsprechenden Accesslisten die Verbreitung dieser Pakete steuern.

Eine Steuerung auf dem Client, indem wir über lokale Firewalls oder Konfiguration des PTP-Clients nur Verbindungen von bestimmten IP-Adressen zulassen, dürfte aber nicht funktionieren, da ein Störer problemlos Source-IP-Adressen bei UDP fälschen kann.

Wenn ich auf PTP angewiesen bin und die Zeitsynchronisierung funktionieren muss, dann sollte auch auf eine Überwachung der Funktion aktivieren. Alle Server als auch die Clients senden ihre Zeit regelmäßig als Multicast über 320/UDP in das Netzwerk und dies kann von allen anderen Teilnehmern mitgelesen und ausgewertet werden. So können Sie z.B.: anhand der MAC-Adresse, die aber auch zu fälschen ist aber im Switch auf einen Port zugeordnet werden kann, die Mitspieler und eventuelle Störer erkennen.

Monitoring

Bei den Spectralink-DECT-Devices ist ein PTP-Monitoring direkt eingebaut. Die Geräte erfassen alle PTP-Pakete und ermitteln insbesondere Jitter, da dies für die Funktion essentiell ist. Hier ein Auszug einer Übersicht

Man sieht gut, dass im LAN1 ein Client einen zu hohen Jitterwert (559ns) hat und im LAN4 wohl entweder ein größeres Problem vorliegt oder sich die Geräte alle über die gleichen Switche/Router zum Master Time Server laufen und daher so viel Jitter haben. Dagegen spricht dann aber die Latenzzeit in Microsekunden (µs)

Es gibt auch kommerzielle Tools, die solche Pakete überwachen können, z.B. mit SFLOW/NetFlow. Aber auch Windows enthält mit W32tm.exe eine Kommandozeile zum Monitoren. Auf meinem Windows 11 Client bin ich aber auf zwei Fehler gelaufen:

  1. Übersetzte Parameter "/Dauer" statt "Duration"
    Die Hilfe auf dem deutschen Windows zeigt den übersetzten Parameter an.
  2. Portkonflikt mit W32time-Dienst
    An einen UDP-Port kann sich immer nur genau ein Prozess binden. Wenn W32time arbeitet, kann W32tm die Pakete nicht erhalten. Die Analyse funktioniert also nur auf einem Windows Client, der selbst kein PTP nutzt oder sie beenden temporär den W32time-Dienst.

Vermutlich ist daher Wireshark das bessere Mittel, die aktuelle Funktion zu überprüfen. Ein passender Filter wäre dann:

udp port 319 or udp port 320

Credits

Die meiste Inhalt der MSXFAQ kommt von mir persönlich aber könnte so nicht existieren, wenn ich keine Einsatzszenarien bei Kunden oder auch Feedback auf Artikel bekomme. Bei diesem Artikel erreichte mich ein sehr wertvolles und qualitatives Feedback von Harald Steindl (https://haraldsteindl.eu) aus Wien, der mir noch sehr viel weitere Aspekte und Tipps geschrieben habt und ich die Seite noch einmal umfangreich erweitert habe. Vielen Dank dafür.

Weitere Links