Was ist TWAMP?

TWAMP (Two-Way Active Measurement Protocol) ist ein standardbasiertes Protokoll, das in RFC 5357 definiert ist und die Netzwerkleistung – Round-Trip-Verzögerung, Einwegverzögerung, Jitter und Paketverlust – zwischen zwei Endpunkten misst. Versa VOS-Geräte und der SASE -Client nutzen es zur Überprüfung der SLA-Einhaltung und zur Messung der Pfadqualität, und zwar im Vollmodus „Full TWAMP“ und im vereinfachten Modus „TWAMP Light“.

Die wichtigsten Erkenntnisse

• TWAMP misst die Hin- und Rücklaufverzögerung, die Einwegverzögerung, den Jitter und den Paketverlust.
• Die Vollversion von TWAMP nutzt einen TCP-Steuerkanal; TWAMP Light verzichtet gänzlich darauf.
• Vier Rollen: Kontroll-Client, Kontroll-Server, Sitzungssender und Reflektor.
• VOS führt TWAMP über LAN-, WAN- und Site-to-Site-IPsec-Tunnel-Schnittstellen aus.
• Die Ergebnisse fließen in die SLA-Prüfungen und die „ Versa “-Analysen ein, nicht jedoch in die automatische Pfadsteuerung.

Auf dieser Seite: Warum das wichtig ist · So funktioniert es · Arten · TWAMP & Versa · Häufig gestellte Fragen

Warum ist TWAMP wichtig?

Netzwerkteams benötigen objektive Messungen der Pfadqualität – Verzögerung, Jitter, Paketverlust –, um festzustellen, ob ein SD-WAN-Pfad sein SLA erfüllt oder ob sich die Leistung einer Verbindung verschlechtert hat, bevor die Nutzer dies bemerken. Ad-hoc-Prüfungen wie der ICMP-Ping sind zu ungenau: Sie erfassen die Einwegverzögerung nicht und unterscheiden nicht zwischen Vorwärts- und Rückwärtsverlust. TWAMP schließt diese Lücke als IETF-Standard (RFC 5357), sodass ein VOS-Gerät einen konformen Test mit einem Gerät eines Drittanbieters durchführen kann und beide Seiten die Ergebnisse auf die gleiche Weise auswerten.

Gerade in gemischten Umgebungen ist Interoperabilität von entscheidender Bedeutung – beispielsweise wenn eine Filiale, auf der VOS läuft, mit dem Nicht-Versa -Gateway eines Partners kommuniziert oder ein „ SASE “-Client seine Zugangsverbindung überprüft. Da TWAMP detaillierte Kennzahlen anstelle eines einfachen „Up/Down“-Signals liefert, können Betreiber die Zahlen mit der Anwendungserfahrung abgleichen und Leistungseinbußen frühzeitig erkennen.

Was ist TWAMP?

TWAMP trennt die Steuerungsebene von der Testebene. Ein Steuerungsclient und ein Steuerungsserver tauschen TCP-Nachrichten (Standardport 862) aus, um Parameter auszuhandeln und die daraus resultierenden Sitzungen zu verwalten. Die Messung selbst läuft zwischen einem Sitzungssender, der UDP-Testpakete überträgt, und einem Sitzungsreflektor, der diese mit einem Zeitstempel versieht und zurücksendet. Für Round-Trip-Metriken ist keine Uhrensynchronisation erforderlich; bei Einweg-Verzögerungsmessungen ist dies jedoch der Fall, sodass für genaue OWD-Werte eine NTP-Synchronisation zwischen Sender und Reflektor erforderlich ist.

Jede Testsitzung läuft auf Abruf oder kontinuierlich, wobei die Paketanzahl, das Intervall und die DSCP-Kennzeichnung konfigurierbar sind, sodass Betreiber eine bestimmte Dienstklasse testen können und nicht nur den „Best-Effort“-Verkehr. Die Ergebnisse – RTT, Jitter, Verlustrate, doppelte und neu angeordnete Pakete – werden über die Log-Export-Funktion (LEF) in „ Versa Analytics“ exportiert.

Arten von TWAMP

VOS unterstützt zwei Betriebsmodi. „Full TWAMP“ führt den kompletten Stack aus: Eine TCP-Steuerungsverbindung handelt Parameter aus und startet anschließend TWAMP-Light-Sitzungen als untergeordnete Sitzungen – geeignet für herstellerübergreifende Konfigurationen, bei denen die dynamische Aushandlung eine manuelle Anpassung der Einstellungen überflüssig macht. TWAMP Light ist die reine Testvariante: kein Kontrollkanal, sondern lediglich ein Sender und ein Reflektor, die UDP-Probes austauschen, die auf jeder Seite unabhängig voneinander konfiguriert werden – für Peers ohne TWAMP Control oder statische Überprüfungen über LAN, WAN und IKEv2-basierte IPsec-Tunnel.

Eine dritte Dimension ist die Einstellung für den Peer-Anbieter, die bei jeder Sitzung festgelegt wird: „Non-Versa “ für allgemeine Drittanbieter-Peers, „ Versa “ für die SLA-Messung über ein Site-to-Site-IPsec-VPN und „RAC Client“ für Auto-SLA-Sitzungen mit einem Remote-Access-Client von Versa SASE .

TWAMP & Versa

Versa VOS implementiert TWAMP Control und TWAMP Light als konfigurierbare Objekte unter „Netzwerk > TWAMP“ in der Appliance-Ansicht von Director – Control-Client- und Server-Sitzungen handeln Parameter aus und verwalten untergeordnete Sitzungen, während eigenständige TWAMP Light-Testsitzungen ausgeführt werden, wenn kein Steuerkanal benötigt wird. Beide sind RFC 5357-konform und arbeiten mit TWAMP-Implementierungen von Drittanbietern sowie anderen VOS-Knoten zusammen.

In der Praxis misst „ Versa “ mithilfe von TWAMP die SD-WAN-Pfadqualität – also die RTT, den Jitter und den Paketverlust, die eine Zweigstelle gerade aufweist, wie unter „Leistungsmessung mit TWAMP“ ausführlich beschrieben – und speist diese Daten in „ Versa Analytics“ ein, um Berichte zur Einhaltung von SLAs zu erstellen. Es handelt sich dabei nicht um einen Mechanismus zur Verkehrssteuerung: Betreiber nutzen die Messwerte, um neben den separaten Pfadauswahlrichtlinien von VOS fundierte Optimierungsentscheidungen zu treffen. Die Peer-Vendor-Option des RAC-Clients erweitert diese Messung auf „ SASE “-Client-Sitzungen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen TWAMP Control und TWAMP Light?

TWAMP Control fügt einen TCP-Kanal hinzu, über den Testparameter zwischen einem Steuerungs-Client und einem Server ausgehandelt werden, und verwaltet anschließend eine oder mehrere untergeordnete Testsitzungen. TWAMP Light verzichtet gänzlich auf den Steuerungskanal – die Parameter für Sender und Reflektor werden unabhängig voneinander konfiguriert, was für Peers geeignet ist, die TWAMP Control nicht unterstützen.

Benötigt TWAMP eine Taktsynchronisation?

Bei Round-Trip-Messungen ist dies nicht der Fall, da beide Zeitstempel von der Uhr des Absenders stammen, wodurch sich etwaige Zeitabweichungen gegenseitig aufheben. Einweg-Verzögerungsmessungen erfordern hingegen synchronisierte Uhren – bei Implementierungen, die genaue OWD-Werte benötigen, sollte NTP zwischen Absender und Reflektor eingerichtet werden, bevor man sich auf diese Werte verlässt.

Kann TWAMP automatische Pfadänderungen in SD-WAN auslösen?

Nein. TWAMP misst zwar die Pfadqualität, steuert jedoch weder die Verkehrslenkung noch Änderungen am Datenpfad. Netzbetreiber nutzen die über „ Versa Analytics“ bereitgestellten Kennzahlen zu RTT, Jitter und Paketverlusten als Grundlage für SLA-Prüfungen und Optimierungsentscheidungen, die separat über die Pfadauswahlrichtlinien von VOS umgesetzt werden.

Welche TCP- und UDP-Ports verwendet TWAMP?

Der Kanal von TWAMP Control ist standardmäßig auf den TCP-Port 862 eingestellt, allerdings ermöglicht VOS den Betreibern, aus Sicherheitsgründen einen vom Standard abweichenden Port zu konfigurieren. Der Testverkehr – die Testpakete zwischen dem Sitzungssender und dem Reflektor – läuft über UDP, in der Regel im dynamischen Portbereich oder auf dem bekannten Port 862.

Was bewirkt die Einstellung „RAC Client – Peer-Anbieter“?

Es konfiguriert eine TWAMP-Sitzung für die automatische SLA-Messung gegenüber einem Remote-Access-Client von Versa SASE anstelle eines Site-to-Site-Peers. Im Vergleich dazu steht Versa, das für die SLA-Messung über ein Site-to-Site-IPsec-VPN zwischen VOS-Geräten verwendet wird, sowie „Non-Versa “, die Standardeinstellung für andere Peers von Drittanbietern.

Mehr zu TWAMP

Wenn Sie mehr erfahren möchten, finden Sie hier Quellen, denen wir vertrauen.

Verwandte Begriffe

Wenn Sie sich gerade über TWAMP informieren, sollten Sie sich als Nächstes diese Artikel ansehen.