What is TWAMP?

TWAMP (Two-Way Active Measurement Protocol) is a standards-based protocol, defined in RFC 5357, that measures network performance – round-trip delay, one-way delay, jitter, and packet loss – between two endpoints. Versa VOS devices and the SASE client use it for SLA compliance checks and path-quality measurement, in Full TWAMP and lightweight TWAMP Light modes.

Key takeaways

• TWAMP measures round-trip delay, one-way delay, jitter, and packet loss.
• Full TWAMP uses a TCP control channel; TWAMP Light skips it entirely.
• Four roles: control client, control server, session sender, and reflector.
• VOS runs TWAMP over LAN, WAN, and site-to-site IPsec tunnel interfaces.
• Results feed SLA checks and Versa Analytics, not automatic path steering.

On this page: Why it matters · How it works · Types · TWAMP & Versa · FAQ

Why is TWAMP important?

Network teams need objective measurements of path quality – delay, jitter, packet loss – to know whether an SD-WAN path is meeting its SLA, or a circuit has degraded before users notice. Ad hoc checks like ICMP ping are too coarse: they miss one-way delay and don’t distinguish forward from reverse loss. TWAMP closes that gap as an IETF standard (RFC 5357), so a VOS device can run a compliant test against a third-party appliance and both sides read the results the same way.

That interoperability matters most in mixed environments – a branch running VOS talking to a partner’s non-Versa gateway, or a SASE client validating its access circuit. Because TWAMP reports granular metrics rather than a single up/down signal, operators can correlate the numbers with application experience and catch degradation early.

What is TWAMP?

TWAMP separates the control plane from the test plane. A control client and control server exchange TCP messages (default port 862) to negotiate parameters and manage the resulting sessions. The measurement itself runs between a session sender, which transmits UDP probe packets, and a session reflector, which timestamps and echoes them back. Round-trip metrics need no clock synchronization; one-way delay measurements do, so accurate OWD figures require NTP between sender and reflector.

Each test session runs on demand or continuously, with configurable packet count, interval, and DSCP marking so operators can test a specific class of service rather than only best-effort traffic. Results – RTT, jitter, loss ratio, duplicate and reordered packets – export to Versa Analytics via log export functionality (LEF).

Types of TWAMP

VOS supports two operational modes. Full TWAMP runs the complete stack: a TCP control connection negotiates parameters, then spins up TWAMP Light sessions as child sessions – suited to multi-vendor setups where dynamic negotiation avoids manually aligning settings. TWAMP Light is the test-only subset: no control channel, just a sender and reflector exchanging UDP probes configured independently on each side, for peers without TWAMP Control or static checks over LAN, WAN, and IKEv2-based IPsec tunnels.

A third dimension is the peer vendor setting each session declares: Non-Versa for general third-party peers, Versa for SLA measurement over a site-to-site IPsec VPN, and RAC Client for auto-SLA sessions against a Versa SASE remote-access client.

TWAMP & Versa

Versa VOS implements TWAMP Control and TWAMP Light as configurable objects under Networking > TWAMP in Director’s Appliance view – control client and server sessions negotiate parameters and manage child sessions, while standalone TWAMP Light test sessions run when no control channel is needed. Both are RFC 5357-compliant, interoperating with third-party TWAMP implementations and other VOS nodes.

In practice, TWAMP is how Versa measures SD-WAN path quality – the RTT, jitter, and loss a branch circuit delivers right now, as detailed in Performance Measurement with TWAMP – feeding Versa Analytics for SLA compliance reporting. It is not a traffic-steering mechanism: operators use its measurements to inform optimization decisions alongside VOS’s separate path-selection policies. The RAC Client peer-vendor option extends the same measurement to SASE client sessions.

Frequently asked questions

What is the difference between TWAMP Control and TWAMP Light?

TWAMP Control adds a TCP channel that negotiates test parameters between a control client and server, then manages one or more child test sessions. TWAMP Light skips the control channel entirely – sender and reflector parameters are configured independently, suiting peers that don’t support TWAMP Control.

Does TWAMP require clock synchronization?

Round-trip measurements don’t, because both timestamps originate from the sender’s own clock, canceling out any clock offset. One-way delay measurements do require synchronized clocks – deployments needing accurate OWD figures should run NTP between sender and reflector before relying on those numbers.

Can TWAMP trigger automatic path changes in SD-WAN?

No. TWAMP measures path quality but doesn’t drive traffic steering or data-path changes. Operators use its RTT, jitter, and loss metrics – surfaced through Versa Analytics – to inform SLA checks and optimization decisions, enforced separately through VOS’s path-selection policies.

What TCP and UDP ports does TWAMP use?

TWAMP Control’s channel defaults to TCP port 862, though VOS lets operators configure a non-default port for security hardening. Test traffic – the probe packets between session sender and reflector – runs over UDP, typically in the dynamic port range or on well-known port 862.

What does the RAC Client peer-vendor setting do?

It configures a TWAMP session for auto-SLA measurement against a Versa SASE remote-access client rather than a site-to-site peer. Compare that to Versa, used for SLA measurement over a site-to-site IPsec VPN between VOS devices, and Non-Versa, the default for other third-party peers.

More on TWAMP

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about TWAMP, these are worth looking at next.