Verständnis 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 anstelle von unidirektionalen Funktionen bidirektionale Messungen oder Round-Trip-Messungen ermöglicht. Zwei-Wege-Messungen sind hilfreich, da Round-Trip-Verzögerungen keine Host-Clock-Synchronisation 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 hat jedoch mehrere Mängel. TWAMP definiert ein offenes Protokoll zur Messung von Zwei-Wege- oder Round-Trip-Metriken mit einer höheren Genauigkeit als andere Methoden durch Verwendung von Zeitstempeln (Verarbeitungsverzögerungen können ebenfalls berücksichtigt werden).
Verwenden Sie den Funktions-Explorer: Zwei-Wege-aktives Messprotokoll , 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-Sondenkonfiguration 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 bidirektionale oder Roundtrip-Metriken mit höherer Genauigkeit als andere Methoden (Verarbeitungsverzögerungen können ebenfalls berücksichtigt werden).
-
TWAMP wird häufig verwendet, um die Einhaltung von Service Level Agreements (SLAs) zu überprüfen, und die TWAMP-Funktion wird in diesem Zusammenhang häufig verwendet.
-
Zwei-Wege-Messungen sind besser als Einweg-Messungen, da Roundtrip-Verzögerungen keine Host-Clock-Synchronisation erfordern. 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 RPM-Sondenergebnissen führen.
Verständnis des bidirektionalen aktiven Messprotokolls (TWAMP)
Normalerweise arbeitet TWAMP zwischen Schnittstellen an zwei Geräten, die bestimmte Rollen spielen. TWAMP wird häufig verwendet, um die Einhaltung von Service Level Agreements (SLAs) 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 auf 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 die Protokolle TWAMP-Test (zwischen Session-Sender und Session-Reflector) ausgeführt.
Die TWAMP-Client-Server-Architektur sieht in der implementierten Form 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 wartet auf Steuermeldungen an einem TCP-Port.
-
Die Verpackung dieser Elemente in TWAMP-Client- und TWAMP-Serverprozesse ist in Abbildung 2 dargestellt.
- Unterstützung für TWAMP-Licht
- Einfache Unterstützung für das bidirektionale aktive Messprotokoll (STAMP)
- Statische Routenverfolgung
- Unterstützung für Segment-Routing für die Konfiguration von Pfaden
- Zeitstempel
Unterstützung für TWAMP-Licht
TWAMP Light, wie in Anhang I von RFC 5357 definiert, ist eine zustandslose Version von TWAMP, bei der Testparameter vordefiniert statt ausgehandelt werden. Alle Testpakete, die der Server auf einem Testport erhält, 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 den Funktions-Explorer: Zwei-Wege-aktives Messprotokoll , um die Plattform- und Release-Unterstützung für bestimmte Funktionen zu bestätigen.
Einfache Unterstützung für das bidirektionale aktive 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. Für Geräte, die STAMP unterstützen, gewährleistet ein STAMP-kompatibler Reflektor 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 Stateful Reflection, 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 Hierarchieebene [edit services monitoring twamp server light] konfiguriert. Zustandsbehaftete Reflektion wird mit der stateful-sequence Anweisung konfiguriert. Für Server ist der neue Standardwert für offload-type now pfe-timestamp anstelle von inline-timestamp.
Verwenden Sie den Feature-Explorer: Simple Two-Way Active Measurement Protocol (STAMP), um die Plattform- und Versionsunterstützung zu bestätigen.
Statische Routenverfolgung
Ab Junos OS Evolved Version 24.4R1 haben wir die Unterstützung für die statische Routenverfolgung auf Junos OS Evolved erweitert und auch Unterstützung für TWAMP-Tests (Two-Way Active Measurement Protocol) hinzugefügt. Sie verwenden TWAMP-Sonden, um den Verbindungsstatus zu ermitteln und den Status der bevorzugten Route auf der Grundlage der Testergebnisse zu ändern. Verfolgte statische Routen können IPv4 oder IPv6 sein, und jede verfolgte statische IPv4- und IPv6-Route unterstützt bis zu 16 nächste Hops. Sie können auch die Metrik, die Routenpräferenz und die 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 sla-tracking Anweisung auf Hierarchieebene [edit routing-options] . Sie verwenden auch einen anderen Befehl, show route sla-tracking, um Informationen zu diesen Routen anzuzeigen.
Unterstützung für Segment-Routing für die Konfiguration von Pfaden
Beginnend mit Junos OS Evolved Version 24.4R1 für die PTX-Router, die es unterstützen, und in Junos OS Version 25.4R1 für die MX-Router, die es unterstützen, haben wir Unterstützung im Two-Way Active Measurement Protocol (TWAMP) für Segment-Routing (SR) gemäß RFC 8402 hinzugefügt, das die SR-Architektur im Großen und Ganzen spezifiziert. 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 IPv6-Routingheader vom Typ 4, der in RFC 8754 eingeführt wurde, wobei jeder Segmentendknoten als IPv6-Adresse oder IPv6-Segmentbezeichner (SID) dargestellt wird.
Sie können die Liste der SR-MPLS- oder SRv6-Segmente angeben, damit eine TWAMP-Sonde den Reflektor erreichen soll. Darüber hinaus können Sie die gleichen Informationen für den Rückweg vom Reflektor zum Client angeben. Diese Rückpfadinformationen werden in die Sondierung selbst eingebettet, indem die in Simple TWAMP (STAMP) Extensions for Segment-Routing Networks, draft-ietf-ippm-stamp-srpm vorgeschlagenen Erweiterungen verwendet werden, nämlich der Rückweg TLV und seine Sub-TLVs der Rückgabesegmentliste, je nach Segment-Routing-Typ. Die TWAMP-Sonden werden entweder in der Routing-Engine oder in der Packet Forwarding Engine mit einem Zeitstempel versehen.
Um diese Funktion für Junos OS Evolved zu konfigurieren, fügen Sie die source-routing Anweisung auf Hierarchieebene [edit services monitoring twamp client control-connection name test-session session-name] ein. Um diese Funktion für Junos OS zu konfigurieren, schließen Sie die source-routing Anweisung auf Hierarchieebene [edit services rpm twamp client control-connection name test-session session-name] ein.
Zeitstempel
Standardmäßig werden für die meisten Plattformen Zeitstempel im Hostprozessor der Packet Forwarding Engine festgelegt. Um die Latenz bei der Kommunikation von Testnachrichten zu berücksichtigen, können Sie die Zeitstempelung der Testpakete auf die Hardware der Packet Forwarding Engine auslagern. Diese Art der Zeitstempelung wird als Inline-Zeitstempel bezeichnet, bei der die Zeitstempelung in der Hardware am Generator oder am Reflektor erfolgt, kurz bevor das Paket das Gerät verlässt. Die Unterstützung für diese Auslagerung und den Inline-Zeitstempel variiert je nach Version, Plattform und Linecard-Unterstützung:
-
Junos OS: Vor Junos OS Version 25.4R1 konnten Sie die Inline-Zeitstempelung aktivieren, indem Sie eine
si-ODER-Schnittstellesp-konfigurierten. Ab Junos OS Version 25.4R1 können Sie für die MX-Linecards, die dies unterstützen, den Zeitstempel mithilfe dieseroffload-type inline-timestampOption auf die Hardware der Packet Forwarding Engine auslagern. Diese Inline-Zeitstempelfunktion unterstützt auch Flex Algo und SR-MPLS.Wenn
si-Schnittstellen auf einem MX-Router für TWAMP konfiguriert sind, ist diese Option die Standardeinstellung für die Zeitstempelung. Um diesi-Schnittstellenimplementierung zu debuggen, müssen Sie entweder dienoneOption oder konfigurierenpfe-timestamp.Sie konfigurieren die
offload-type (inline-timestamp | none | pfe-timestamp)Anweisung auf einer dieser Hierarchieebenen:[edit services rpm twamp client control-connection name test-session name],[edit services rpm twamp server]oder[edit services rpm twamp server light]. -
Weiterentwickeltes Junos OS: Zeitstempel werden von der Routing-Engine oder der Packet Forwarding Engine für IPv4-Datenverkehr festgelegt. Für IPv6-Datenverkehr werden Zeitstempel nur von der Routing-Engine festgelegt. 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 die
offload-typeAnweisung auf IPv6-Datenverkehr[edit services monitoring twamp client control-connection name test-session name]für IPv6-Datenverkehr alsnonekonfiguriert werden. Ab Junos OS Evolved Version 22.4R1 können Sie für unterstützte Geräte dieinline-timestampingOption deroffload-typeAnweisung konfigurieren, um von der Hardware inline gesetzte Zeitstempel zu aktivieren. Ab Junos OS Evolved Version 23.4R1 für Server ist die Standardeinstellung für dieoffload-typeAnweisung jetztpfe-timestampanstelle voninline-timestamp. Ab Junos OS Evolved Version 25.4R1 unterstützt die Inline-Zeitstempelfunktion auch Flex Algo und SR-MPLS.
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 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.
-
Sondenstatistiken und -verlauf
-
Sitzungsstatus kontrollieren und testen
-
Testsitzungs-Sondengenerierung und -empfang sowie Reflexion
-
Fehlermeldung nur über Systemprotokollmeldungen und SNMP-Traps
-
Nur nicht authentifizierter Modus
Die Unterstützung von Junos OS Evolved für TWAMP umfasst auch einige Funktionen, die nicht in Junos OS 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 von RFC 5357, Zwei-Wege-aktives Messprotokoll (TWAMP), definiert wurde. Weitere Informationen finden Sie unter Unterstützung für Simple Bi-Way Active Measurement Protocol (STAMP).
-
Ab Junos OS Evolved Version 24.4R1 unterstützen wir die statische Routenverfolgung mit TWAMP für die Geräte, die diese Funktion unterstützen. Weitere Informationen finden Sie unter Verfolgung statischer Routen .
Plattformspezifisches TWAMP-Verhalten
Verwenden Sie den Funktions-Explorer: Zwei-Wege-aktives Messprotokoll , um die Plattform- und Release-Unterstützung für bestimmte Funktionen zu bestätigen.
In der folgenden Tabelle finden Sie Informationen zu plattformspezifischen Verhaltensweisen für Ihre Plattform.
| Plattform-Unterschied | |
|---|---|
| ACX-Serie |
|
| EX-Serie |
Sowohl der Steuerungsclient als auch der Sitzungssender (der TWAMP-Client) befinden sich auf demselben Juniper Networks Router. Der TWAMP-Client erfordert jedoch nicht, dass sich der Server und der Sitzungsreflektor auf demselben System befinden. Daher kann der Juniper TWAMP-Client mit einer Serverimplementierung eines Drittanbieters verwendet werden. |
| MX-Serie |
|
| PTX-Serie |
|
| QFX10000-Serie |
Sowohl der Steuerungsclient als auch der Sitzungssender (der TWAMP-Client) befinden sich auf demselben Juniper Networks Router. Der TWAMP-Client erfordert jedoch nicht, dass sich der Server und der Sitzungsreflektor auf demselben System befinden. Daher kann der Juniper TWAMP-Client mit einer Serverimplementierung eines Drittanbieters verwendet werden. |
| QFX5000 Serie (Junos OS weiterentwickelt) |
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 RPM-Client- und Serverunterstützung, TWAMP-Client- (mit der Steuerungs-Komponente) und TWAMP-Server-Unterstützung (mit der Responder-Komponente) und der Hardware, die den Zeitstempel ausführt.
| Unterstützung von TWAMP-Funktionen |
Zeitstempel der Routing-Engine |
MS-PIC/MS-DPC-Zeitstempel |
MS-MIC/MS-MPC-Zeitstempel |
Zeitstempel der Packet Forwarding Engine (Mikrokernel) |
Zeitstempel der Packet Forwarding Engine (LU) ( |
| RPM Client |
Nein |
Nein |
Nein |
Nein |
Nein |
| RPM-Server |
Nein |
Nein |
Nein |
Nein |
Nein |
| TWAMP Client |
Nein |
Nein |
Nein |
Nein |
Nein |
| TWAMP-Server |
Nein |
Nein |
Nein |
Ja (keine Responder-Konfiguration erforderlich) |
Nein |
Die Unterstützung für die Serviceschnittstellen (sp-, ms-, und si- Schnittstellen) unterscheidet sich alle geringfügig.
Tabelle 3 enthält Informationen über TWAMP der MX-Serie und die zugehörige Unterstützung von Zeitstempeln auf MPC, MS-MIC/MPC und Inline:
| Funktion |
Rolle |
IP-Version |
Unterstützung (ja/nein) |
Zeitstempel Inline |
Zeitstempel auf MPC (Hardware-Zeitstempel) |
Zeitstempel auf MPC (Si-Schnittstelle) |
Zeitstempel auf MS-MIC/MPC (Delegate-Probes) |
|---|---|---|---|---|---|---|---|
| ZWEIFLE |
Managed Client |
IPv4 |
Y |
N |
Y (μsec) Maximal 1000 Sonden |
Y (μsec) Maximal 1000 Sonden |
N |
| IPv6 |
N |
N |
N |
N |
N |
||
| Managed Server |
IPv4 |
Y |
N |
Y (μsec) Maximal 1000 Sonden |
Y (μsec) Maximal 1000 Sonden |
N |
|
| IPv6 |
N |
N |
N |
N |
N |
| Funktion |
Rolle |
IP-Version |
Unterstützung (ja/nein) |
Zeitstempel Inline |
Zeitstempel auf MPC (Hardware-Zeitstempel) |
Zeitstempel auf MPC (Si-Schnittstelle) |
Zeitstempel auf MS-MIC/MPC (Delegate-Probes) |
|---|---|---|---|---|---|---|---|
| ZWEIFLE |
Light Client |
IPv4 |
Y |
Y (μsec) (ab Version 25.4R1) Maximal 1000 Sonden |
Y (μsec) Maximal 1000 Sonden |
Y (μsec) Maximal 1000 Sonden |
N |
| IPv6 |
Y |
Y (μsec) (ab Version 25.4R1) Maximal 1000 Sonden |
Y (μsec) Maximal 1000 Sonden |
Y (μsec) Maximal 1000 Sonden |
N |
||
| Light Server |
IPv4 |
Y |
Y (μsec) (ab Version 25.4R1) Maximal 1000 Sonden |
Y (μsec) Maximal 1000 Sonden |
Y (μsec) Maximal 1000 Sonden |
N |
|
| IPv6 |
Y |
Y (μsec) (ab Version 25.4R1) Maximal 1000 Sonden |
Y (μsec) Maximal 1000 Sonden |
Y (μsec) Maximal 1000 Sonden |
N |