Welche QoS-Klassifizierung sollte auf NTP angewendet werden?

In der Enterprise QoS-Lösungsreferenz von Cisco wird vorgeschlagen , NTP als Netzwerkverwaltungsdatenverkehr zu klassifizieren und als CS2 zu kennzeichnen:

Cisco empfiehlt die folgenden Richtlinien, um die QoS-Anforderungen des Netzwerkverwaltungsverkehrs zu erfüllen:

Der Netzwerkverwaltungsverkehr sollte für DSCP CS2 markiert sein.

Netzwerkverwaltungsanwendungen sollten explizit mit einer minimalen Bandbreitengarantie geschützt werden.

Der Netzwerkverwaltungsverkehr ist wichtig, um Trend- und Kapazitätsanalysen und Fehlerbehebungen durchzuführen. Daher können Sie eine separate Warteschlange mit minimaler Bandbreite für den Netzwerkverwaltungsverkehr bereitstellen , die SNMP, NTP , Syslog, NFS und andere Verwaltungsanwendungen umfassen kann .

Warum wird NTP nicht als beschleunigte Weiterleitung markiert und genauso behandelt wie Sprachdaten, da NTP jitterempfindlich ist?

Gibt es einen Grund, warum es nicht in dieselbe Warteschlange mit geringer Latenz wie Voice gestellt werden sollte?

— Stephen Craven
quelle

Ich denke nicht, dass "jitterempfindlich" eine faire Charakterisierung von NTP ist. Dies erklärt viel, aber ich glaube, dass der Algorithmus und die Abfrageintervalle mit einer gewissen Menge an Jitter umgehen können. Das würde mich zu der Annahme führen, dass es nicht gleichbedeutend mit der Stimme behandelt werden muss. (Ich weiß allerdings wenig über QoS.)

— Craig Constantine

@CraigConstantine Das stimmt. In den meisten Umgebungen sind Sie wahrscheinlich 95% der Daten voraus, solange Sie eine Warteschlange haben, um den BE-Verkehr zu unterbinden.

— Ryan Foley

@CraigConstantine werfen Sie einen Blick auf RFP4594 Guter Fang Stephen. Ich denke, Cisco stimmt nicht mit der IETF in diesem

— Ronnie Royston

Cisco ist ein großes Unternehmen mit vielen verschiedenen Einzelpersonen / Gruppen. Nicht alle sind sich immer einig, was am besten ist. Persönlich denke ich, dass die IETF-Empfehlung besser ist, wenn es um "hochgenaues Timing" geht, aber ich persönlich möchte nicht, dass NTP für meine Netzwerkgeräte (die ich im Allgemeinen nicht als hochgenau einstufen würde) "Wanduhr-Timing" ist DF wie der RFC es ausdrückt. Die Cisco-Empfehlung scheint eher "mitten auf der Straße" zu sein und entspricht den Erwartungen, die ich an die allgemeinen NTP-Anforderungen für Netzwerkgeräte stellen würde.

— YLearn

@StevenCraven, damit diese Frage beantwortet werden kann, müssen wir verstehen, welche Genauigkeitsanforderungen Sie für NTP haben und wie es verwendet wird.

— Mike Pennington

Antworten:

Bearbeitete Antwort: NTP sollte gemäß den RFC 4594-Konfigurationsrichtlinien der IETF für DiffServ-Serviceklassen in die EF-Klasse eingefügt werden (wie Echtzeit-Sprachpakete) .

5.2. Zuordnung für NTP

Aus Tests, die durchgeführt wurden, geht hervor, dass eine genaue Zeitverteilung einen Transport mit sehr geringer Paketverzögerungsvariation (Jitter) erfordert. Daher empfehlen wir, die folgenden Richtlinien für das Network Time Protocol (NTP) zu verwenden:

o Wenn NTP verwendet wird, um ein hochgenaues Timing innerhalb des Netzwerks eines Administrators (Netzbetreibers) oder für Endbenutzer / Clients bereitzustellen, sollte die Telefoniedienstklasse verwendet werden , und NTP-Pakete sollten mit dem EF DSCP-Wert markiert werden.

o Für Anwendungen, die eine Zeitgenauigkeit für die Wanduhr erfordern, sollte die Standarddienstklasse verwendet und Pakete mit DF DSCP gekennzeichnet werden.

— Ronnie Royston
quelle

oben korrigiert

— Ronnie Royston

NTP ist nicht besonders Jitter-empfindlich , weil es verwendet originateund transmitZeitstempel Spur der Verzögerung zu halten. Ntp.org erklärt ausführlich, wie es die Verzögerung in Schach hält , aber hier ist ein Ausschnitt:

Das Synchronisieren eines Clients mit einem Netzwerkserver besteht aus mehreren Paketvermittlungen, wobei jede Vermittlung ein Paar aus Anforderung und Antwort ist. Beim Versenden einer Anfrage speichert der Client seine eigene Zeit (Ursprungszeitstempel) in dem zu sendenden Paket. Wenn ein Server ein solches Paket empfängt, speichert er seinerseits seine eigene Zeit (Empfangszeitstempel) im Paket, und das Paket wird zurückgegeben, nachdem ein Sendezeitstempel in das Paket eingefügt wurde. Beim Empfang der Antwort protokolliert der Empfänger erneut seine eigene Empfangszeit, um die Reisezeit des Pakets zu schätzen. Die Fahrzeit (Verzögerung) wird unter der Annahme symmetrischer Verzögerungen auf die Hälfte der "Gesamtverzögerung abzüglich der Fernverarbeitungszeit" geschätzt.

Der Grund dafür, dass dies nicht in derselben Kategorie wie die Netzwerksteuerung liegt, liegt darin, dass dies nicht direkt für den Betrieb des Weiterleitens / Weiterleitens von Paketen verantwortlich ist. Alle Dinge in der Kategorie Netzwerkverwaltung sind keine kritischen Komponenten des gesamten Netzwerksystems. Wenn Sie Pakete im Zusammenhang mit SNMP, Syslog oder NTP verloren haben, werden Sie es wahrscheinlich gar nicht bemerken.

SNMP würde diese Informationen einfach erneut übertragen, da sie auf TCP basieren. Selbst wenn die Verbindung alle zusammen unterbrochen würde, würde nichts Katastrophales passieren; Möglicherweise antwortet ein snmp-Agent nicht und versucht es dann erneut. Wenn Sie den Syslog-Verkehr (UDP) verloren haben, verlieren Sie einfach einen Streifen Protokollierungsinformationen, die wahrscheinlich noch im Puffer oder in einer Protokolldatei auf dem Gerät enthalten sind. Da NTP die Verzögerung basierend auf vorherigen Paketen berechnet und gleichzeitig den maximalen Versatzfehler berücksichtigt, treten keine Probleme auf. Im schlimmsten Fall verschiebt sich Ihre Zeit um einige Pikosekunden…

Wenn Sie ein Paket im Zusammenhang mit dem Routing auch nur für eine Sekunde verloren haben, kann es sein, dass das gesamte System ausfällt. andere Markierungen wertlos machen. Zu diesem Zeitpunkt würde NTP einfach nicht mehr synchron sein und sich auf den lokalen Ticker verlassen, um die Zeit zu halten.

— Ryan Foley
quelle