AUF DIESER SEITE
Grundlegendes zum bidirektionalen aktiven Messprotokoll
ZUSAMMENFASSUNG 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.
Vorteile von TWAMP
-
Die TWAMP-Konfiguration hilft Ihnen, Ihr Netzwerk End-to-End zu aktivieren, zu testen, zu überwachen und Fehler zu beheben, ohne ein spezielles 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 Zusammenhang verwendet.
-
Zwei-Wege-Messungen sind besser als unidirektionale Messungen, da für Round-Trip-Verzögerungen keine Synchronisierung der Hostuhr erforderlich ist. Dies ist möglich, weil der Reflektor eine eigene Sequenznummer in das Paket einfügt.
Es wird empfohlen, den RPM-Client und einen TWAMP-Server nicht auf demselben Gerät zu konfigurieren. Dies kann zu Problemen bei den Ergebnissen der Drehzahlsonde führen.
TWAMP (Two-Way Active Measurement Protocol) verstehen
Das in RFC 5357 beschriebene Two-Way Active Management Protocol (TWAMP) ist eine Erweiterung des One-Way Active Management Protocol (OWAMP), das bidirektionale oder Round-Trip-Messungen anstelle von unidirektionalen Funktionen bereitstellt. Zwei-Wege-Messungen sind hilfreich, da Round-Trip-Verzögerungen keine Synchronisierung der Hostuhr erfordern und Remote-Support eine einfache Echofunktion sein kann. Das Internet Control Message Protocol (ICMP) Echo Request/Reply (von Ping verwendet) für diesen Zweck weist jedoch mehrere Mängel auf. TWAMP definiert ein offenes Protokoll zur Messung von Zwei-Wege- oder Round-Trip-Metriken mit größerer Genauigkeit als andere Methoden unter Verwendung von Zeitstempeln (Verarbeitungsverzögerungen können ebenfalls berücksichtigt werden).
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 häufig in diesem Zusammenhang vorgestellt. TWAMP verwendet zwei verwandte Protokolle, die zwischen mehreren definierten Elementen ausgeführt werden:
-
TWAMP-Control: Initiiert, 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 ausführen können, können verschiedene Geräte unterschiedliche Rollen spielen. Eine gemeinsame 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 läuft auf jedem Gerät sowohl das TWAMP-Control- (zwischen Control-Client und Server) als auch das TWAMP-Test-Protokoll (zwischen Session-Sender und Session-Reflector).
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
-
Der 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 Bündelung dieser Elemente in TWAMP-Client- und TWAMP-Server-Prozesse ist in Abbildung 2 dargestellt.
Tabelle 1 enthält Informationen über TWAMP und die damit verbundene Zeitstempelunterstützung auf MPC, MS-MIC/MPC und Inline:
| Feature |
Rolle |
IP-Version |
Unterstützung (J/N) |
Zeitstempel Inline |
Zeitstempel auf MPC (Hardware-Zeitstempel) |
Zeitstempel auf MPC (si-Schnittstelle) |
Zeitstempel auf MS-MIC/MPC (Delegate-Probes) |
|---|---|---|---|---|---|---|---|
| TWAMP |
Kunde |
IPv4 |
Y |
N |
Y (μsec) Maximal 500 Sonden |
Y (μsec) Maximal 500 Sonden |
N |
| IPv6 |
N |
N |
N |
N |
N |
||
| Server
|
IPv4 |
Y |
N |
Y (μsec) Maximal 500 Sonden |
Y (μsec) Maximal 500 Sonden |
N |
|
| IPv6 |
N |
N |
N |
N |
N |
- TWAMP Light-Unterstützung
- Einfache Unterstützung für das bidirektionale aktive Messprotokoll (STAMP)
TWAMP Light-Unterstützung
Tabelle 2 enthält Informationen zur Unterstützung von TWAMP Light, wie in Anhang I von RFC 5357 definiert, der eine Light-Version des TWAMP-Protokolls definiert, eine zustandslose Version von TWAMP, bei der Testparameter vordefiniert und nicht ausgehandelt werden. Alle Testpakete, die der Server auf einem Testport empfängt, werden zurückgeworfen und vergessen sofort.
Die Unterstützung für IPv6-Zieladressen für TWAMP Light-Testsitzungen wurde in Junos OS Version 21.3R1 eingeführt und ist in der folgenden Tabelle aufgeführt.
Die Unterstützung für IPv6-Link-Local-Zieladressen wurde in Junos OS Version 21.4R1 für die MX-Serie und die Router PTX1000, PTX3000 und PTX5000 sowie in Junos OS Evolved Version 22.3R1 für die Router ACX7100, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008 und PTX10016 eingeführt.
| Geräte | , die in |
|---|---|
| ACX710 | Junos OS Version 22.3R1 |
| ACX5448 Serie | Junos OS Version 22.3R1 |
| ACX7100-Serie | Junos OS Evolved Version 21.2R1 |
| ACX7509 | Junos OS Evolved Version 22.3R1 |
| MX-Serie mit LC480, LC2101, LC2103 und MPCs bis einschließlich MPC9E | Junos OS Version 21.1R1 (IPv4), Junos OS Version 21.3R1 (IPv6) |
| MX-Serie mit den folgenden Linecards: LMIC16-BASE, LC9600, MPC10E und MPC11E |
|
| PTX-Serie mit Junos OS, mit MPCs bis einschließlich MPC9E | Junos OS Version 21.1R1 (IPv4), Junos OS Version 21.3R1 (IPv6) |
| PTX-Serie mit Junos OS und MPC10E- und MPC11E-Linecards |
|
| PTX10001-36MR |
|
| PTX10003 |
|
| PTX10004 |
|
| PTX10008 und PTX10016 (mit dem JNP10008-SF3 und der Linecard JNP10K-LC1201 oder JNP10K-LC1202-36MR) |
|
| QFX5130-32CD, QFX5220 und QFX5700 | Junos OS Evolved 22.4R1 (IPv4 und IPv6) |
| QFX10002, QFX10008 und QFX10016 | Junos OS Version 21.3R1 (IPv4) |
| EX9200 | Junos OS Version 21.4R1 |
Einfache Unterstützung für das bidirektionale aktive Messprotokoll (STAMP)
Tabelle 3 enthält Informationen zur Unterstützung für TWAMP Light, wie in RFC 8762, Simple Two-Way Active Measurement Protocol (STAMP ), definiert. RFC 8762 standardisiert und erweitert den Betriebsmodus TWAMP Light, der in Anhang I von RFC 5357, Two-Way Active Measurement Protocol (TWAMP), definiert wurde. Ein STAMP-kompatibler Reflektor gewährleistet 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 Reflektion unterstützt. Wir unterstützen jetzt zustandsbehaftete Reflektion, vollständige Konformität mit dem STAMP-Standard 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 Hierarchieebene [edit services monitoring twamp server light] konfiguriert. Die zustandsbehaftete Reflektion wird mit der stateful-sequence Anweisung konfiguriert. Bei Servern ist der neue Standardwert für offload-type jetzt pfe-timestamp anstelle von inline-timestamp.
| Gerät |
Unterstützt in |
|---|---|
| ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7509 |
Junos OS Evolved Version 23.4R1 |
| PTX10001-36MR, PTX10003, PTX10004 sowie PTX10008 und PTX10016 (mit dem JNP10008-SF3 und der Linecard JNP10K-LC1201 oder JNP10K-LC1202-36MR) |
Junos OS Evolved Version 23.4R1 |
TWAMP auf Routern der MX-Serie, Switches der EX9200-Serie und der QFX10000-Serie
Sowohl der Kontroll-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 Sitzungsreflektor auf demselben System befinden. Daher ist der TWAMP-Client von Juniper in der Lage, mit einer Serverimplementierung eines Drittanbieters zu arbeiten.
TWAMP wird nicht unterstützt, wenn Sie Next Gen Services auf einem Router der MX-Serie aktivieren.
TWAMP auf Routern der PTX-Serie
Das TWAMP-Control-Protokoll wird verwendet, um Leistungsmesssitzungen zwischen einem TWAMP-Client und einem TWAMP-Server einzurichten, und das TWAMP-Test-Protokoll wird verwendet, um Leistungsmesssonden zu senden und zu empfangen. Das Zielschnittstellenattribut si-x/y/z , das für die Aktivierung von Inline-Diensten vorgesehen ist, wird auf Routern der PTX-Serie für TWAMP-Client-Konfigurationen nicht unterstützt.
Für Junos OS wird TWAMP auf Hierarchieebene [edit services rpm twamp] konfiguriert. Für Junos OS Evolved wird TWAMP auf Hierarchieebene [edit services monitoring twamp] konfiguriert. Tabelle 4 enthält Informationen zur Unterstützung von TWAMP.
| Geräte | , die in |
|---|---|
| PTX-Serie mit Junos OS | Junos OS Version 19.2R1 |
| PTX10001-36MR |
|
| PTX10003 |
|
| PTX10004 |
|
| PTX10008 (mit der JNP10008-SF3 und der Linecard JNP10K-LC1201 oder JNP10K-LC1202-36MR) |
|
| PTX10016 (mit der JNP10008-SF3 und der Linecard JNP10K-LC1201 oder JNP10K-LC1202-36MR) | Junos OS Evolved Version 22.4R1 (IPv4 und IPv6) |
Die Unterstützung von Junos OS Evolved für TWAMP ist auf Folgendes beschränkt:
-
IPv4- und IPv6-Datenverkehr nur für Steuerungssitzungen und Testsitzungen. Ab Junos OS Evolved Version 21.4R1 werden IPv6-Quell- und -Zieladressen (mit Ausnahme von Link-Local-Adressen) für Clientlisten, Steuerverbindungen und Testsitzungen unterstützt.
-
Probe-Statistiken und -Verlauf
-
Status der Kontroll- und Testsitzung
-
Erzeugen und Empfangen von Testsitzungen sowie Reflektion
-
Zeitstempel, die von der Routing-Engine oder der Paketweiterleitungs-Engine für IPv4-Datenverkehr festgelegt werden. Für IPv6-Datenverkehr nur Zeitstempel, die von der Routing-Engine festgelegt werden. Für IPv6-Datenverkehr unterstützen wir ab Junos OS Evolved 22.3R1 Zeitstempel der Packet Forwarding Engine. Vor Junos OS Evolved Version 22.3R1 sollte für IPv6-Datenverkehr die
offload-typeAnweisung auf Hierarchieebene[edit services monitoring twamp client control-connection name test-session name]alsnonekonfiguriert werden. Ab Junos OS Evolved 23.4R1 für Server lautet die Standardeinstellung für dieoffload-typeAnweisung jetztpfe-timestampanstelle voninline-timestamp. -
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 Betriebsmodus TWAMP Light, der in Anhang I von RFC 5357, Two-Way Active Measurement Protocol (TWAMP), definiert wurde. Weitere Informationen finden Sie unter Einfache Unterstützung für das bidirektionale aktive Messprotokoll (STAMP).
-
Fehlerberichte nur über Systemprotokollmeldungen und SNMP-Traps
-
Nur nicht authentifizierter Modus
TWAMP auf Switches der QFX5000-Serie
Das TWAMP-Control-Protokoll wird verwendet, um Leistungsmesssitzungen zwischen einem TWAMP-Client und einem TWAMP-Server einzurichten, und das TWAMP-Test-Protokoll wird verwendet, um Leistungsmesssonden zu senden und zu empfangen. Für Junos OS Evolved wird TWAMP auf Hierarchieebene [edit services monitoring twamp] konfiguriert.
| Geräte | , die in |
|---|---|
| QFX5130-32CD | Junos OS Evolved Version 22.4R1 |
| QFX5220 | Junos OS Evolved Version 22.4R1 |
| QFX5700 | Junos OS Evolved Version 22.4R1 |
Die Unterstützung von Junos OS Evolved für TWAMP ist auf Folgendes beschränkt:
-
IPv4- und IPv6-Quell- und Zieladressen (einschließlich Link-Local-Adressen) werden für Clientlisten, Steuerverbindungen und Testsitzungen unterstützt.
-
Probe-Statistiken und -Verlauf
-
Status der Kontroll- und Testsitzung
-
Erzeugen und Empfangen von Testsitzungen sowie Reflektion
-
Zeitstempel, die von der Routing-Engine oder von der Paketweiterleitungs-Engine für IPv4- und IPv6-Datenverkehr festgelegt werden.
-
Fehlerberichte nur über Systemprotokollmeldungen und SNMP-Traps
-
Nur nicht authentifizierter Modus
TWAMP auf Firewalls der SRX-Serie
Für SRX300-, SRX320-, SRX340-, SRX345-, SRX550M-, SRX1500-, SRX4100- und SRX4200-Geräte und virtuelle vSRX-Firewall-Instanzen gelten die folgenden Einschränkungen für die TWAMP-Unterstützung:
-
TWAMP für IPv6 wird nicht unterstützt.
-
TWAMP-Server- und TWAMP-Client-Authentifizierung werden nicht unterstützt.
-
TWAMP Light wird nicht unterstützt.
TWAMP auf Routern der ACX-Serie
In Junos OS wird TWAMP für ACX-Router unterstützt. Die Router der Serien ACX710 und ACX5448 unterstützen sowohl Reflektion als auch Generierung. Andere Router der ACX-Serie mit Junos OS unterstützen nur Reflektion, nicht Generierung. Für Junos OS wird TWAMP auf Hierarchieebene [edit services rpm twamp] konfiguriert.
In Junos OS Evolved wird TWAMP für ACX-Router unterstützt, sowohl für Reflektion als auch für die Generierung. Ab Junos OS Evolved 21.2R1 wird TWAMP (einschließlich TWAMP Light) für die Router der ACX7100-Serie unterstützt. Für Junos OS Evolved wird TWAMP auf Hierarchieebene [edit services monitoring twamp] konfiguriert. Die Unterstützung von Junos OS Evolved für TWAMP ist auf Folgendes beschränkt:
-
IPv4-Datenverkehr nur für Kontrollsitzungen und Testsitzungen; Unterstützung für IPv6-Datenverkehr (mit Ausnahme von Link-Local-Adressen) ab Junos OS Evolved Version 21.4R1. Unterstützung für IPv6-Link-Local-Adressen für TWAMP Light-Testsitzungen nur ab Junos OS Evolved 22.3R1.
-
Probe-Statistiken und -Verlauf
-
Status der Kontroll- und Testsitzung
-
Erzeugen und Empfangen von Testsitzungen sowie Reflektion
Zeitstempel, die von der Routing-Engine oder der Paketweiterleitungs-Engine für IPv4-Datenverkehr festgelegt werden. Für IPv6-Datenverkehr nur Zeitstempel, die von der Routing-Engine festgelegt werden. Für IPv6-Datenverkehr unterstützen wir ab Junos OS Evolved 22.3R1 Zeitstempel der Packet Forwarding Engine. Vor Junos OS Evolved Version 22.3R1 sollte für IPv6-Datenverkehr die
Ab Junos OS Evolved 23.4R1 lautet der Standardwert für dieoffload-typeAnweisung auf Hierarchieebene[edit services monitoring twamp client control-connection name test-session name]alsnonekonfiguriert werden. Ab Junos OS Evolved 22.4R1 für ACX-Router können Sie die Option der Anweisung so konfigurieren, dass Zeitstempel aktiviert werden, dieinline-timestampinginline von deroffload-typeHardware festgelegt werden.offload-typeAnweisung jetztpfe-timestampanstelle voninline-timestamp.-
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 Betriebsmodus TWAMP Light, der in Anhang I von RFC 5357, Two-Way Active Measurement Protocol (TWAMP), definiert wurde. Weitere Informationen finden Sie unter Einfache Unterstützung für das bidirektionale aktive Messprotokoll (STAMP).
-
Fehlerberichte nur über Systemprotokollmeldungen
-
Nur nicht authentifizierter Modus