Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

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.

Anmerkung:

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:

Abbildung 1: Vier Elemente von TWAMP Four Elements of TWAMP

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.

Abbildung 2: Die Elemente von TWAMP implementiert als Client (links) und Server (rechts). The Elements of TWAMP Implemented as Client (Left) and Server (Right).

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 offload-type Anweisung auf IPv6-Datenverkehr [edit services monitoring twamp client control-connection name test-session name] wie folgt nonekonfiguriert werden. Ab Junos OS Evolved Version 22.4R1 können Sie für unterstützte Geräte die inline-timestamping Option der offload-type Anweisung so konfigurieren, dass von der Hardware inline festgelegte Zeitstempel aktiviert werden.

    Ab Junos OS Evolved Version 23.4R1 für Server ist die Standardeinstellung für die offload-type Anweisung jetzt pfe-timestamp anstelle von inline-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.

Tabelle 1: Plattformspezifisches TWAMP-Verhalten
Plattformunterschied

ACX-Serie

  • Im Junos OS unterstützen die Router der ACX710- und ACX5448-Serie sowohl Reflection als auch Generierung. Andere Router der ACX-Serie, die unter Junos OS ausgeführt werden, unterstützen nur die Reflektion, nicht die Generierung.

  • In Junos OS Evolved wird TWAMP für ACX-Router sowohl für die Reflexion als auch für die Generierung unterstützt. Hinweise zu OS-Unterschieden bei der TWAMP-Unterstützung finden Sie unter Junos OS Evolved – Unterschiede bei der TWAMP-Unterstützung .

  • Für Junos OS wird TWAMP auf der [edit services rpm twamp] Hierarchieebene konfiguriert. Für Junos OS Evolved wird TWAMP auf der [edit services monitoring twamp] Hierarchieebene konfiguriert.

  • Der Verbindungsdatenverkehr der TWAMP-Steuerung kommt immer auf ACX-Routern an, wobei der lauschende Port auf 862 festgelegt ist. Da diese Portnummer für Traffic Probes geändert werden kann, werden Sondierungen, die mit einer anderen Portnummer eintreffen, von ACX-Routern nicht erkannt und nicht ordnungsgemäß verarbeitet. Infolgedessen werden in einem solchen Szenario TWAMP-Datenverkehr und an den Host gebundene Pakete verworfen.

  • Für inline-timestamping den Modus können der TWAMP-Client und -Server nicht auf demselben ACX-Router konfiguriert werden.

  • Für inline-timestamping den Modus wird TWAMP über Layer-3-VPN nicht unterstützt.

  • Vor Junos OS Evolved Version 23.4R1 löscht der TWAMP-Client die TWAMP-Sondierungen, wenn sowohl TWAMP als auch CFM (Connectivity Fault Management) konfiguriert sind. Entfernen Sie die CFM-Konfiguration, um TWAP zu aktivieren. Ab Junos OS Evolved Version 23.4R1 können Sie CFM auf demselben Gerät wie TWAP konfigurieren.

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

  • 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.

  • TWAMP wird nicht unterstützt, wenn Sie Services der nächsten Generation auf einem Router der MX-Serie aktivieren.

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 [edit services monitoring twamp] Hierarchieebene konfiguriert. Hinweise zu OS-Unterschieden bei der TWAMP-Unterstützung finden Sie unter Junos OS Evolved – Unterschiede bei der TWAMP-Unterstützung .

SRX-Serie (SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100 und SRX4200 Geräte und Virtuelle Firewall vSRX Instanzen)

  • TWAMP für IPv6 wird nicht unterstützt.

  • TWAMP-Server- und TWAMP-Client-Authentifizierung werden nicht unterstützt.

  • TWAMP Light wird nicht unterstützt.

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.

Tabelle 2: TWAMP-Funktionsunterstützung und -Hardware für Junos OS, MX-Serie

TWAMP-Funktionsunterstützung

Zeitstempel der Routing-Engine

MS-PIC/MS-DPC-Zeitstempel

MS-MIC/MS-MPC-Zeitstempel

Zeitstempel der Packet Forwarding Engine (Microkernel)

Zeitstempelsi- der Packet Forwarding Engine (LU)

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
Anmerkung:

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:

Tabelle 3: TWAMP und zugehörige Zeitstempel-Unterstützung, MX-Serie

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

Zugehörige Dokumentation