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 zweiwegigen aktiven Messprotokolls

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 durchgängig 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 höherer Genauigkeit als andere Methoden (Verarbeitungsverzögerungen können auch einkalkiert werden).

  • TWAMP wird häufig verwendet, um die Einhaltung von SLA (Service Level Agreement) zu überprüfen, und die TWAMP-Funktion wird in diesem Zusammenhang häufig verwendet.

  • Zweiwegmessungen sind besser als One-Way-Messungen, da Hin- und Rücklaufverzögerungen keine Synchronisierung der Host-Taktung erfordern. Dies ist möglich, weil der Reflektor seine eigene Sequenznummer in das Paket legt.

Hinweis:

Wir empfehlen, den RPM-Client und einen TWAMP-Server nicht auf demselben Gerät zu konfigurieren. Dies kann zu Problemen in den ERGEBNISSEN der RPM-Probe führen.

Zweiwegiges aktives Messprotokoll (TWAMP) verstehen

Das Two-Way Active Management Protocol (TWAMP), beschrieben in RFC 5357, ist eine Erweiterung des One-Way Active Management Protocol (OWAMP), das zwei- oder Rundwegmessungen anstelle unidirektionaler Funktionen liefert. Zwei-Wege-Messungen sind hilfreich, da Round-Trip-Verzögerungen keine Host-Taktsynchronisierung erfordern und Remote-Unterstützung eine einfache Echofunktion sein kann. Allerdings weist das Internet Control Message Protocol (ICMP) Echo Request/Reply (verwendet von Ping) zu diesem Zweck mehrere Mängel auf. TWAMP definiert ein offenes Protokoll zur Messung von Zweiweg- oder Round-Trip-Metriken mit höherer Genauigkeit als bei anderen Methoden durch Verwendung von Zeitstempeln (Auch Verarbeitungsverzögerungen können einkalkiert werden).

Normalerweise funktioniert TWAMP zwischen Schnittstellen auf zwei Geräten, die eine bestimmte Rolle spielen. TWAMP wird häufig verwendet, um die Einhaltung der Service Level Agreement (SLA) zu überprüfen, und die TWAMP-Funktion wird in diesem Kontext häufig dargestellt. TWAMP verwendet zwei verwandte Protokolle, die zwischen mehreren definierten Elementen ausgeführt werden:

  • TWAMP-Control: Initiiert, startet und beendet Testsitzungen. Das TWAMP-Control-Protokoll wird zwischen einem Control-Client-Element und einem Serverelement ausgeführt.

  • TWAMP-Test: Austausch von Testpaketen zwischen zwei TWAMP-Elementen. 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 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 im anderen Gerät (bekannt als TWAMP-Responder oder TWAMP-Server). In diesem Fall führt jedes Gerät sowohl die Protokolle TWAMP-Control (zwischen Control-Client und Server) als auch TWAMP-Test (zwischen Session-Sender und Session-Reflector) aus.

Die implementierte TWAMP-Client-Server-Architektur sieht wie folgt aus:

  • TWAMP-Client

    • Control-Client richtet die TWAMP-Testsitzungen ein, startet und stoppt sie.

    • 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, führt aber keine Aufzeichnung dieser Informationen.

    • Der Server verwaltet eine oder mehrere Sitzungen mit dem TWAMP-Client und lauscht auf Steuernachrichten an einem TCP-Port.

Die Verpackung 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).

Tabelle 1 enthält Informationen über TWAMP und die damit verbundene Zeitstempelunterstützung für MPC, MS-MIC/MPC und Inline:

Tabelle 1: TWAMP und entsprechende Zeitstempelunterstützung

Feature

Rolle

IP-Version

Support (Y/N)

Timestamp Inline

Zeitstempel auf MPC (Hardware-Zeitstempel)

Zeitstempel auf MPC (si-interface)

Zeitstempel auf MS-MIC/MPC (Delegate-Probes)

TWAMP

Kunde

IPv4

Y

N

Y (μsec)

500 maximale Sonden

Y (μsec)

500 maximale Sonden

N

IPv6

N

N

N

N

N

Server

IPv4

Y

N

Y (μsec)

500 maximale Sonden

Y (μsec)

500 maximale Sonden

N

IPv6

N

N

N

N

N

Tabelle 2 enthält Informationen zur Unterstützung für TWAMP Light, wie im Anhang I von RFC 5357 definiert, in dem eine Light-Version des TWAMP-Protokolls definiert wird, eine zustandslose Version von TWAMP, bei der Testparameter vordefiniert sind, anstatt zu ausgehandelt werden. Alle Testpakete, die vom Server an einem Testport empfangen werden, werden zurückgespiegelt und sofort vergessen.

Die Unterstützung von IPv6-Zieladressen für TWAMP Light-Testsitzungen wird in Junos OS Version 21.3R1 und wie in der nachstehenden Tabelle erwähnt, eingeführt.

Unterstützung für link-lokale IPv6-Zieladressen wird in Junos OS Version 21.4R1 für die MX-Serie und den PTX1000 eingeführt, ROUTER PTX3000 und PTX5000 sowie in Junos OS Evolved Version 22.3R1 für die Router ACX7100, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008 und PTX10016.

Tabelle 2: TWAMP Light Support
Unterstütztes Gerät 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
  • IPv4-Client: Junos OS Version 21.1R1
  • IPv4-Server: Junos OS Version 22.2R1

  • IPv6-Client und -Server: Junos OS Version 22.3R1
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 mit MPC10E und MPC11E Linecards
  • Client: Junos OS Version 21.1R1 (IPv4)
  • Server: Junos OS Version 22.2R1 (IPv4)
PTX10001-36MR

  • Junos OS Evolved Version 21.1R1 (IPv4)

  • Junos OS Evolved Version 21.4R1 (IPv6)
PTX10003

  • Junos OS Evolved Version 20.3R1 (IPv4)

  • Junos OS Evolved Version 21.4R1 (IPv6)
PTX10004

  • Junos OS Evolved Version 21.2R1 (IPv4)

  • Junos OS Evolved Version 21.4R1 (IPv6)
PTX10008 und PTX10016 (mit der JNP10008-SF3 und entweder der Linecard JNP10K-LC1201 oder JNP10K-LC1202-36MR)

  • Junos OS Evolved Version 21.1R1 (IPv4)

  • Junos OS Evolved Version 21.4R1 (IPv6)
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

TWAMP auf Routern der MX-Serie, Switches der EX9200- und QFX10000-Serie

Sowohl der Control-Client als auch der Sitzungsversender (der TWAMP-Client) befinden sich auf demselben Router von Juniper Networks. Der TWAMP-Client erfordert jedoch nicht, dass sich Server und Sitzungsreflektor auf demselben System befinden. Daher ist der Juniper TWAMP-Client in der Lage, mit einer Serverimplementierung von Drittanbietern zu arbeiten.

Hinweis:

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

TWAMP auf Routern der PTX-Serie

Das TWAMP-Control-Protokoll wird verwendet, um Leistungsmessungen zwischen einem TWAMP-Client und einem TWAMP-Server einzurichten, und das TWAMP-Test-Protokoll wird zum Senden und Empfangen von Leistungsmessungssonden verwendet. Das Zielschnittstellen-Attribut si-x/y/z , das für die Aktivierung von Inline-Services bestimmt ist, wird auf Routern der PTX-Serie für TWAMP-Client-Konfigurationen nicht unterstützt.

Für Junos OS wird TWAMP auf [edit services rpm twamp] Hierarchieebene konfiguriert. Für Junos OS Evolved wird TWAMP auf [edit services monitoring twamp] Hierarchieebene konfiguriert. Tabelle 3 enthält Informationen zur Unterstützung für TWAMP.

Tabelle 3: TWAMP-Unterstützung der PTX-Serie
Unterstütztes Gerät in
PTX-Serie mit Junos OS Junos OS-Version 19.2R1
PTX10001-36MR

  • Junos OS Evolved Version 21.1R1 (IPv4)

  • Junos OS Evolved Version 22.4R1 (IPv6)
PTX10003

  • Junos OS Evolved Version 20.3R1 (IPv4)

  • Junos OS Evolved Version 22.4R1 (IPv6)
PTX10004

  • Junos OS Evolved Version 21.2R1 (IPv4)

  • Junos OS Evolved Version 22.4R1 (IPv6)
PTX10008 (mit der JNP10008-SF3 und entweder der Linecard JNP10K-LC1201 oder JNP10K-LC1202-36MR)

  • Junos OS Evolved Version 21.1R1 (IPv4)

  • Junos OS Evolved Version 22.4R1 (IPv6)
PTX10016 (mit der JNP10008-SF3 und entweder der JNP10K-LC1201 oder JNP10K-LC1202-36MR Linecard)

Junos OS Evolved Version 22.4R1 (IPv4 und IPv6)

Die Junos OS Evolved-Unterstützung 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 (außer link-lokale Adressen) für Client-Listen, Steuerungsverbindungen und Testsitzungen unterstützt.

  • Probe-Statistik und -Verlauf

  • Steuerungs- und Testsitzungsstatus

  • Generierung und Empfang von Probe-Testsitzungen sowie Reflexion

  • Zeitstempel, die von der Routing-Engine oder der Packet Forwarding Engine für IPv4-Datenverkehr festgelegt werden. Für IPv6-Datenverkehr werden nur Zeitstempel von der Routing-Engine festgelegt. Für IPv6-Datenverkehr ab Junos OS Evolved 22.3R1 unterstützen wir Zeitstempel der Packet Forwarding Engine. Vor Junos OS Evolved Version 22.3R1 sollte für IPv6-Datenverkehr die offload-type Anweisung auf [edit services monitoring twamp client control-connection name test-session name] Hierarchieebene als nonekonfiguriert werden.

  • Fehlerberichte nur über Systemprotokollmeldungen und SNMP-Traps

  • Nur nicht authentifizierter Modus

TWAMP auf Switches der QFX5000-Serie

Das TWAMP-Control-Protokoll wird verwendet, um Leistungsmessungen zwischen einem TWAMP-Client und einem TWAMP-Server einzurichten, und das TWAMP-Test-Protokoll wird zum Senden und Empfangen von Leistungsmessungssonden verwendet. Für Junos OS Evolved wird TWAMP auf [edit services monitoring twamp] Hierarchieebene konfiguriert.

Tabelle 4: Unterstützung für TWAMP der QFX5000-Serie
Unterstütztes Gerät in
QFX5130-32CD Junos OS Evolved Version 22.4R1
QFX5220 Junos OS Evolved Version 22.4R1
QFX5700 Junos OS Evolved Version 22.4R1

Die Junos OS Evolved-Unterstützung für TWAMP ist auf folgendes beschränkt:

  • IPv4- und IPv6-Quell- und Zieladressen (einschließlich link-lokaler Adressen) werden für Clientlisten, Steuerungsverbindungen und Testsitzungen unterstützt.

  • Probe-Statistik und -Verlauf

  • Steuerungs- und Testsitzungsstatus

  • Generierung und Empfang von Probe-Testsitzungen sowie Reflexion

  • Zeitstempel, die von der Routing-Engine oder von der Packet Forwarding Engine für IPv4- und IPv6-Datenverkehr festgelegt werden.

  • Fehlerberichte nur über Systemprotokollmeldungen und SNMP-Traps

  • Nur nicht authentifizierter Modus

TWAMP auf SRX-Geräten

SrX300-, SRX320-, SRX340-, SRX345-, SRX550M-, SRX1500-, SRX4100- und SRX4200-Geräte und vSRX-Instanzen haben 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 ACX710- und ACX5448-Serie unterstützen sowohl Reflexion als auch Generation. Andere Router der ACX-Serie mit Junos OS unterstützen nur Reflexion, nicht Generierung. Für Junos OS wird TWAMP auf [edit services rpm twamp] Hierarchieebene konfiguriert.

In Junos OS Evolved wird TWAMP für ACX-Router unterstützt, sowohl zur Reflexion als auch zur 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 [edit services monitoring twamp] Hierarchieebene konfiguriert. Die Junos OS Evolved-Unterstützung für TWAMP ist auf folgendes beschränkt:

  • IPv4-Datenverkehr nur für Kontroll- und Testsitzungen; Unterstützung für IPv6-Datenverkehr (außer link-lokale Adressen) ab Junos OS Evolved Version 21.4R1. Unterstützung für link-lokale IPv6-Adressen nur für TWAMP Light-Testsitzungen, die in Junos OS Evolved 22.3R1 beginnen.

  • Probe-Statistik und -Verlauf

  • Steuerungs- und Testsitzungsstatus

  • Generierung und Empfang von Probe-Testsitzungen sowie Reflexion

  • Zeitstempel, die von der Routing-Engine oder der Packet Forwarding Engine für IPv4-Datenverkehr festgelegt werden. Für IPv6-Datenverkehr werden nur Zeitstempel von der Routing-Engine festgelegt. Für IPv6-Datenverkehr ab Junos OS Evolved 22.3R1 unterstützen wir Zeitstempel der Packet Forwarding Engine. Vor Junos OS Evolved Version 22.3R1 sollte für IPv6-Datenverkehr die offload-type Anweisung auf [edit services monitoring twamp client control-connection name test-session name] Hierarchieebene als nonekonfiguriert werden. Ab Junos OS Evolved 22.4R1 für ACX-Router können Sie die Option der inline-timestamping offload-type Anweisung so konfigurieren, dass Zeitstempel aktiviert werden, die von der Hardware inline festgelegt werden.

  • Fehlerberichte nur über Systemprotokollmeldungen

  • Nur nicht authentifizierter Modus

Ähnliche Dokumentation