Verstehen des bidirektionalen aktiven Messprotokolls
Erfahren Sie mehr über die Verwendung des Two-Way Active Measurement Protocol (TWAMP) zur Messung der Netzwerkleistung zwischen zwei beliebigen Geräten in einem Netzwerk.
Das in RFC 5357 beschriebene Two-Way Active Management Protocol (TWAMP) ist eine Erweiterung des One-Way Active Management Protocol (OWAMP), das Zwei-Wege- oder Round-Trip-Messungen anstelle von unidirektionalen Funktionen liefert. Zwei-Wege-Messungen sind hilfreich, da Round-Trip-Verzögerungen keine Synchronisierung der Host-Uhr erfordern und Remote-Support eine einfache Echofunktion sein kann. Das Internet Control Message Protocol (ICMP) Echo Request/Reply (das zu diesem Zweck von ping verwendet wird) weist jedoch einige Mängel auf. TWAMP definiert ein offenes Protokoll für die Messung von Zwei-Wege- oder Round-Trip-Metriken mit größerer Genauigkeit als andere Methoden durch die Verwendung von Zeitstempeln (Verarbeitungsverzögerungen können ebenfalls berücksichtigt werden).
Verwenden Sie Feature Explorer: Two-Way Active Measurement Protocol , um die Plattform- und Release-Unterstützung für bestimmte Funktionen zu bestätigen.
Im Abschnitt Plattformspezifisches TWAMP-Verhalten finden Sie Hinweise zu Ihrer Plattform.
Vorteile von TWAMP
-
Die TWAMP-Probe-Konfiguration hilft Ihnen, Ihr Netzwerk End-to-End zu aktivieren, zu testen, zu überwachen und Fehler zu beheben, ohne ein dediziertes Testgerät zu verwenden.
-
TWAMP-Zeitstempel bieten Zwei-Wege- oder Round-Trip-Metriken mit größerer Genauigkeit als andere Methoden (Verarbeitungsverzögerungen können ebenfalls berücksichtigt werden).
-
TWAMP wird häufig verwendet, um die Einhaltung von Service Level Agreements (SLA) zu überprüfen, und die TWAMP-Funktion wird häufig in diesem Kontext verwendet.
-
Zwei-Wege-Messungen sind besser als unidirektionale Messungen, da Round-Trip-Verzögerungen keine Host-Taktsynchronisation erfordern. Dies ist möglich, weil der Reflektor eine eigene Sequenznummer in das Paket legt.
Es wird empfohlen, den RPM-Client und einen TWAMP-Server nicht auf demselben Gerät zu konfigurieren. Dies kann zu Problemen in den RPM-Testergebnissen führen.
Grundlegendes zum bidirektionalen aktiven Messprotokoll (TWAMP)
Normalerweise arbeitet TWAMP zwischen Schnittstellen auf zwei Geräten, die bestimmte Rollen spielen. TWAMP wird häufig verwendet, um die Einhaltung von Service Level Agreements (SLA) zu überprüfen, und die TWAMP-Funktion wird oft in diesem Zusammenhang vorgestellt. TWAMP verwendet zwei verwandte Protokolle, die zwischen mehreren definierten Elementen laufen:
-
TWAMP-Control – Startet, startet und beendet Testsitzungen. Das TWAMP-Control-Protokoll läuft zwischen einem Control-Client-Element und einem Server-Element.
-
TWAMP-Test – Tauscht Testpakete zwischen zwei TWAMP-Elementen aus. Das TWAMP-Test-Protokoll läuft zwischen einem Session-Sender-Element und einem Session-Reflector-Element.
Die vier Elemente sind in Abbildung 1 dargestellt:

Obwohl vier verschiedene TWAMP-Geräte die vier logischen Rollen TWAMP Control-Client, Server, Session-Sender und Session-Reflector erfüllen können, können verschiedene Geräte unterschiedliche Rollen spielen. Eine gängige Implementierung kombiniert die Rollen von Control-Client und Session-Sender in einem Gerät (bekannt als TWAMP-Controller oder TWAMP-Client) und die Rollen von Server und Session-Reflector in dem anderen Gerät (bekannt als TWAMP-Responder oder TWAMP-Server). In diesem Fall werden auf jedem Gerät sowohl die Protokolle TWAMP-Control (zwischen Control-Client und Server) als auch TWAMP-Test (zwischen Session-Sender und Session-Reflector) ausgeführt.
Die implementierte TWAMP-Client-Server-Architektur sieht wie folgt aus:
-
TWAMP-Client
-
Control-Client richtet, startet und stoppt die TWAMP-Testsitzungen.
-
Session-Sender erstellt TWAMP-Testpakete, die an den Session-Reflector im TWAMP-Server gesendet werden.
-
-
TWAMP-Server
-
Session-Reflector sendet ein Messpaket zurück, wenn ein Testpaket empfangen wird, zeichnet diese Informationen jedoch nicht auf.
-
Der Server verwaltet eine oder mehrere Sitzungen mit dem TWAMP-Client und lauscht auf Steuermeldungen an einem TCP-Port.
-
Die Paketierung dieser Elemente in TWAMP-Client- und TWAMP-Serverprozesse ist in Abbildung 2 dargestellt.

- TWAMP Light Support
- Unterstützung für einfaches bidirektionales aktives Messprotokoll (STAMP)
- Statisches Routen-Tracking
- Segment-Routing-Unterstützung für die Konfiguration von Pfaden
TWAMP Light Support
TWAMP Light, wie in Anhang I von RFC 5357 definiert, ist eine zustandslose Version von TWAMP, bei der Testparameter vordefiniert und nicht ausgehandelt werden. Alle Testpakete, die der Server an einem Testport empfängt, werden zurückgeworfen und sofort vergessen. Für die Geräte, die sie unterstützen, können Sie auch IPv6-Zieladressen konfigurieren, einschließlich link-lokaler IPv6-Zieladressen.
Verwenden Sie Feature Explorer: Two-Way Active Measurement Protocol , um die Plattform- und Release-Unterstützung für bestimmte Funktionen zu bestätigen.
Unterstützung für einfaches bidirektionales aktives Messprotokoll (STAMP)
Wie in RFC 8762, Simple Two-Way Active Measurement Protocol, definiert, standardisiert und erweitert STAMP den TWAMP Light-Betriebsmodus, der in Anhang I von RFC 5357, Two-Way Active Measurement Protocol (TWAMP), definiert wurde. Bei Geräten, die STAMP unterstützen, sorgt ein STAMP-konformer Reflektor für eine symmetrische Nutzlastgröße (gemäß RFC 6038) und arbeitet entweder im zustandslosen oder im zustandsbehafteten Modus, je nachdem, ob die Sequenznummer in der reflektierten Nutzlast aus dem Client-Frame kopiert oder unabhängig generiert wird. Ein Stateful-Reflektor kann erkennen, in welche Richtung Stürze aufgetreten sind. In früheren Versionen haben wir symmetrische Nutzlasten und zustandslose Reflexion unterstützt. Wir unterstützen zustandsbehaftete Reflektion, vollständige Einhaltung des STAMP-Standards und unidirektionale Drop-Werte für Clients. Wir unterstützen unidirektionale Drop-Werte nicht nur für STAMP-Clients, sondern auch für TWAMP-Managed-Mode-Clients. Für Junos OS Evolved wird STAMP auf der [edit services monitoring twamp server light]
Hierarchieebene konfiguriert. Die zustandsbehaftete Reflektion wird mit der stateful-sequence
Anweisung konfiguriert. Bei Servern ist die neue Standardeinstellung für offload-type
jetzt pfe-timestamp
anstelle von inline-timestamp
.
Verwenden Sie Feature Explorer: Simple Two-Way Active Measurement Protocol (STAMP), um die Plattform- und Release-Unterstützung zu bestätigen.
Statisches Routen-Tracking
Ab Junos OS Evolved Version 24.4R1 haben wir die Unterstützung für die statische Routenverfolgung auf Junos OS Evolved erweitert und auch die Unterstützung für Two-Way Active Measurement Protocol (TWAMP)-Tests integriert. Sie verwenden TWAMP-Sonden, um den Verbindungsstatus zu erkennen und den Status der bevorzugten Route auf der Grundlage der Sondierungsergebnisse zu ändern. Nachverfolgte statische Routen können IPv4 oder IPv6 sein, und jede nachverfolgte statische IPv4- und IPv6-Route unterstützt bis zu 16 Next Hops. Sie können auch die Metrik-, Routenpräferenz- und Tag-Werte für jedes IPv4- oder IPv6-Zielpräfix konfigurieren. Sie konfigurieren diese Funktion jedoch auf Junos OS Evolved-Geräten anders. Sie konfigurieren die Anweisung sla-tracking
auf Hierarchieebene [edit routing-options]
. Sie verwenden auch einen anderen Befehl, show route sla-tracking
, um Informationen zu diesen Routen anzuzeigen.
Segment-Routing-Unterstützung für die Konfiguration von Pfaden
Ab Junos OS Evolved Version 24.4R1 haben wir für die PTX-Router, die dies unterstützen, Unterstützung im Two-Way Active Measurement Protocol (TWAMP) für Segment-Routing (SR) gemäß der Definition in RFC 8402 hinzugefügt, in dem die SR-Architektur allgemein festgelegt ist. Wir unterstützen zwei Arten von SR für TWAMP-Sonden:
-
SR-MPLS: Verwendet eine Liste von Beschriftungen, die jeweils einen Segmentendknoten darstellen.
-
SRv6: Verwendet einen in RFC 8754 eingeführten IPv6-Routing-Header vom Typ 4, wobei jeder Segmentendknoten als IPv6-Adresse oder IPv6-Segment-ID (SID) dargestellt wird.
Sie können die Liste der SR-MPLS- oder SRv6-Segmente angeben, damit eine TWAMP-Sonde den Reflektor erreichen kann. Darüber hinaus können Sie die gleichen Informationen für den Rückweg vom Reflektor zum Client angeben. Diese Rückgabepfadinformationen werden in die Sondierung selbst eingebettet, indem die Erweiterungen verwendet werden, die in Simple TWAMP (STAMP) Extensions for Segment-Routing Networks, draft-ietf-ippm-stamp-srpm, vorgeschlagen werden, nämlich das Rückgabepfad-TLV und seine Rückgabesegmentlisten-Unter-TLVs, je nach Segment-Routing-Typ. Die TWAMP-Sondierungen werden entweder in der Routing-Engine oder in der Packet Forwarding Engine mit einem Zeitstempel versehen.
Um diese Funktion zu konfigurieren, schließen Sie die source-routing
Anweisung auf Hierarchieebene [edit services monitoring twamp client control-connection name test-session session-name
ein.
Junos OS Evolved – Unterschiede bei der TWAMP-Unterstützung
Die Unterstützung von Junos OS Evolved für TWAMP ist auf Folgendes beschränkt:
-
IPv4- und IPv6-Datenverkehr nur für Kontrollsitzungen und Testsitzungen. Ab Junos OS Evolved Version 21.4R1 werden IPv6-Quell- und -Zieladressen (mit Ausnahme von Link-Local-Adressen) für Client-Listen, Steuerverbindungen und Testsitzungen unterstützt.
-
Untersuchungsstatistiken und -verlauf
-
Sitzungsstatus steuern und testen
-
Testsitzung Probe-Generierung und -Empfang sowie Reflexion
Zeitstempel, die von der Routing-Engine oder der Packet Forwarding Engine für IPv4-Datenverkehr festgelegt werden. Für IPv6-Datenverkehr nur Zeitstempel, die von der Routing-Engine festgelegt werden. Für IPv6-Datenverkehr ab Junos OS Evolved 22.3 R1 unterstützen wir die Zeitstempel der Packet Forwarding Engine. Vor Junos OS Evolved Version 22.3R1 sollte die
Ab Junos OS Evolved Version 23.4R1 für Server ist die Standardeinstellung für dieoffload-type
Anweisung auf IPv6-Datenverkehr[edit services monitoring twamp client control-connection name test-session name]
wie folgtnone
konfiguriert werden. Ab Junos OS Evolved Version 22.4R1 können Sie für unterstützte Geräte dieinline-timestamping
Option deroffload-type
Anweisung so konfigurieren, dass von der Hardware inline festgelegte Zeitstempel aktiviert werden.offload-type
Anweisung jetztpfe-timestamp
anstelle voninline-timestamp
.-
Fehlerberichterstattung nur über System-Log-Meldungen und SNMP-Traps
-
Nur nicht authentifizierter Modus
Die Junos OS Evolved-Unterstützung für TWAMP umfasst auch einige Funktionen, die in Junos OS nicht enthalten sind:
-
Ab Junos OS Evolved Version 23.4R1 unterstützen wir RFC 8762, Simple Two-Way Active Measurement Protocol (STAMP). RFC 8762 standardisiert und erweitert den TWAMP Light-Betriebsmodus, der in Anhang I des RFC 5357, Two-Way Active Measurement Protocol (TWAMP), definiert wurde. Weitere Informationen finden Sie unter Unterstützung für einfaches bidirektionales aktives Messprotokoll (STAMP).
-
Ab Junos OS Evolved Version 24,4R1 unterstützen wir die statische Routenverfolgung mit TWAP für die Geräte, die diese Funktion unterstützen. Weitere Informationen finden Sie unter Statische Routenverfolgung .
-
Beginnend mit Junos OS Evolved Version 24.4R1 haben wir für die PTX-Router, die dies unterstützen, Unterstützung im Two-Way Active Measurement Protocol (TWAMP) für Segment-Routing (SR) gemäß Definition in RFC 8402 hinzugefügt. Weitere Informationen finden Sie unter Segment-Routing-Unterstützung für das Konfigurieren von Pfaden .
Plattformspezifisches TWAMP-Verhalten
Verwenden Sie Feature Explorer: Two-Way Active Measurement Protocol , um die Plattform- und Release-Unterstützung für bestimmte Funktionen zu bestätigen.
Verwenden Sie die folgende Tabelle, um plattformspezifische Verhaltensweisen für Ihre Plattform zu überprüfen.
Plattformunterschied | |
---|---|
ACX-Serie |
|
EX-Serie |
Sowohl der Steuerungs-Client als auch der Sitzungssender (der TWAMP-Client) befinden sich auf demselben Router von Juniper Networks. Für den TWAMP-Client ist es jedoch nicht erforderlich, dass sich der Server und der Session-Reflector auf demselben System befinden. Daher ist der TWAMP-Client von Juniper in der Lage, mit einer Serverimplementierung eines Drittanbieters zu arbeiten. |
MX-Serie |
|
PTX-Serie |
|
QFX 10000-Serie |
Sowohl der Steuerungs-Client als auch der Sitzungssender (der TWAMP-Client) befinden sich auf demselben Router von Juniper Networks. Für den TWAMP-Client ist es jedoch nicht erforderlich, dass sich der Server und der Session-Reflector auf demselben System befinden. Daher ist der TWAMP-Client von Juniper in der Lage, mit einer Serverimplementierung eines Drittanbieters zu arbeiten. |
QFX5000 Serie (Junos OS Evolved) |
Für Junos OS Evolved wird TWAMP auf der |
SRX-Serie (SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100 und SRX4200 Geräte und Virtuelle Firewall vSRX Instanzen) |
|
Für die MX-Serie zeigt die folgende Tabelle die Beziehung zwischen der Unterstützung von RPM-Clients und -Servern, der Unterstützung von TWAMP-Clients (mit der Steuerungskomponente) und des TWAMP-Servers (mit der Responder-Komponente) sowie der Hardware, die den Zeitstempel ausführt.
TWAMP-Funktionsunterstützung |
Zeitstempel der Routing-Engine |
MS-PIC/MS-DPC-Zeitstempel |
MS-MIC/MS-MPC-Zeitstempel |
Zeitstempel der Packet Forwarding Engine (Microkernel) |
Zeitstempel |
RPM-Client |
Ja |
Ja |
Ja |
Ja |
Nein |
RPM-Server |
Ja |
Ja |
Ja |
Ja |
Nein |
TWAMP-Client |
Nein |
Nein |
Nein |
Ja |
Ja |
TWAMP-Server |
Nein |
Ja |
Nein |
Ja (keine Responder-Konfiguration erforderlich) |
Ja |
Die Unterstützung für die Dienstschnittstellen (sp-
und si-
ms-
Schnittstellen) ist geringfügig unterschiedlich.
Tabelle 3 enthält Informationen über TWAMP der MX-Serie und die damit verbundene Zeitstempelunterstützung auf MPC, MS-MIC/MPC und inline:
Merkmal |
Rolle |
IP-Version |
Unterstützung (ja/nein) |
Zeitstempel Inline |
Zeitstempel auf MPC (Hardware-Zeitstempel) |
Zeitstempel auf MPC (si-Schnittstelle) |
Zeitstempel auf MS-MIC/MPC (Delegat-Sonden) |
---|---|---|---|---|---|---|---|
TWAMP |
Kunde |
IPv4 |
Y |
N |
Y (μsec) max. 500 Sonden |
Y (μsec) max. 500 Sonden |
N |
IPv6-Schnittstelle |
N |
N |
N |
N |
N |
||
Server
|
IPv4 |
Y |
N |
Y (μsec) max. 500 Sonden |
Y (μsec) max. 500 Sonden |
N |
|
IPv6-Schnittstelle |
N |
N |
N |
N |
N |