Understand Two-Way Active Measurement Protocol
Learn about using Two-Way Active Measurement Protocol (TWAMP) to measure network performance between any two devices in a network.
The Two-Way Active Management Protocol (TWAMP), described in RFC 5357, is an extension of the One-Way Active Management Protocol (OWAMP) that supplies two-way or round-trip measurements instead of unidirectional capabilities. Two-way measurements are helpful because round-trip delays do not require host clock synchronization and remote support might be a simple echo function. However, the Internet Control Message Protocol (ICMP) Echo Request/Reply (used by ping) for this purpose has several shortcomings. TWAMP defines an open protocol for measuring two-way or round-trip metrics with greater accuracy than other methods by using time-stamps (processing delays can be factored as well).
Use Feature Explorer: Two-Way Active Measurement Protocol to confirm platform and release support for specific features.
Review the Platform-Specific TWAMP Behavior section for notes related to your platform.
Benefits of TWAMP
-
TWAMP probe configuration helps you activate, test, monitor, and troubleshoot your network end-to-end without using a dedicated testing device.
-
TWAMP timestamps provide two-way or round-trip metrics with greater accuracy than other methods (processing delays can be factored as well).
-
TWAMP is often used to check service-level agreement (SLA) compliance, and the TWAMP feature is often used in that context.
-
Two-way measurements are better than one-way measurements because round-trip delays do not require host clock synchronization. This is possible because the reflector places its own sequence number in the packet.
We recommend that you do not configure the RPM client and a TWAMP server on the same device. This might cause some issues in the RPM probe results.
Understand Two-Way Active Measurement Protocol (TWAMP)
Usually, TWAMP operates between interfaces on two devices playing specific roles. TWAMP is often used to check Service Level Agreement (SLA) compliance, and the TWAMP feature is often presented in that context. TWAMP uses two related protocols, running between several defined elements:
-
TWAMP-Control—Initiates, starts, and ends test sessions. The TWAMP-Control protocol runs between a Control-Client element and a Server element.
-
TWAMP-Test—Exchanges test packets between two TWAMP elements. The TWAMP-Test protocol runs between a Session-Sender element and a Session-Reflector element.
The four elements are shown in Figure 1:

Although four different TWAMP devices can perform the four logical roles of TWAMP Control-Client, Server, Session-Sender, and Session-Reflector, different devices can play different roles. A common implementation combines the roles of Control-Client and Session-Sender in one device (known as the TWAMP controller or TWAMP client) and the roles of Server and Session-Reflector in the other device (known as the TWAMP responder or TWAMP server). In this case, each device runs both the TWAMP-Control (between Control-Client and Server) and TWAMP-Test (between Session-Sender and Session-Reflector) protocols.
The TWAMP client-server architecture as implemented looks like this:
-
TWAMP client
-
Control-Client sets up, starts and stops the TWAMP test sessions.
-
Session-Sender creates TWAMP test packets that are sent to the Session-Reflector in the TWAMP server.
-
-
TWAMP server
-
Session-Reflector sends back a measurement packet when a test packet is received, but does not maintain a record of such information.
-
Server manages one or more sessions with the TWAMP client and listens for control messages on a TCP port.
-
The packaging of these elements into TWAMP client and TWAMP server processes is shown in Figure 2.

- TWAMP Light Support
- Simple Two-Way Active Measurement Protocol (STAMP) Support
- Static Route Tracking
- Segment Routing Support for Configuring Paths
TWAMP Light Support
TWAMP Light, as defined in Appendix I of RFC 5357, is a stateless version of TWAMP where test parameters are predefined instead of negotiated. All test packets received by the server on a test port are reflected back and forgotten right away. For those devices that support them, you can also configure IPv6 target addresses, including IPv6 link-local target addresses.
Use Feature Explorer: Two-Way Active Measurement Protocol to confirm platform and release support for specific features.
Simple Two-Way Active Measurement Protocol (STAMP) Support
As
defined in RFC 8762,
Simple Two-Way Active Measurement
Protocol,
STAMP standardizes and expands upon the TWAMP Light
operational mode, which was defined in Appendix I of RFC 5357, Two-Way
Active Measurement Protocol (TWAMP).
For those
devices that support STAMP, a STAMP-compliant reflector
ensures symmetric payload size (in accordance with RFC 6038) and operates in
either stateless or stateful mode, depending on whether the sequence number in
the reflected payload is copied from the client frame or generated
independently. A stateful reflector can detect in which direction drops have
occurred. In previous releases, we supported symmetric payloads and stateless
reflection. We
support
stateful reflection, full compliance with the STAMP standard, and unidirectional
drop values for clients. We support unidirectional drop values not only for
STAMP clients, but also for TWAMP-Managed-mode clients. For Junos OS Evolved,
STAMP is configured at the [edit services monitoring twamp server
light]
hierarchy level. Stateful reflection is configured with the
stateful-sequence
statement. For servers, the new default
for offload-type
is now pfe-timestamp
instead
of inline-timestamp
.
Use Feature Explorer: Simple Two-Way Active Measurement Protocol (STAMP) to confirm platform and release support.
Static Route Tracking
Starting in Junos OS Evolved Release 24.4R1, we've extended support for static
route tracking to Junos OS Evolved and included Two-Way Active Measurement
Protocol (TWAMP) test support as well. You use TWAMP probes to detect link
status and to change the preferred-route state on the basis of the probe
results. Tracked static routes can be IPv4 or IPv6, and each IPv4 and IPv6
tracked static route supports up to 16 next hops. You can also configure the
metric, route preference, and tag values for each IPv4 or IPv6 destination
prefix. However, you configure this feature differently on Junos OS Evolved
devices; you configure the sla-tracking
statement at the
[edit routing-options]
hierarchy level. You also use a
different command, show route sla-tracking
, to see information
about these routes.
Segment Routing Support for Configuring Paths
Starting in Junos OS Evolved Release 24.4R1, for those PTX routers that support it, we have added support in Two-Way Active Measurement Protocol (TWAMP) for segment routing (SR) as defined in RFC 8402, which broadly specifies the SR architecture. We support two types of SR for TWAMP probes:
-
SR-MPLS: Uses a list of labels, each representing a segment end node.
-
SRv6: Uses a type 4 IPv6 routing header introduced in RFC 8754, with each segment end node represented as an IPv6 address or IPv6 segment identifier (SID).
You can specify the list of SR-MPLS or SRv6 segments for a TWAMP probe to reach the reflector. In addition, you can specify the same information for the return path from the reflector to the client. This return path information is embedded in the probe itself by using the extensions proposed in Simple TWAMP (STAMP) Extensions for Segment Routing Networks, draft-ietf-ippm-stamp-srpm, namely the return path TLV and its return segment list sub-TLVs, as appropriate depending on the segment routing type. The TWAMP probes are timestamped in either the Routing Engine or the Packet Forwarding Engine.
To configure this feature, include the source-routing
statement
at the [edit services monitoring twamp client control-connection
name test-session
session-name
hierarchy level.
Junos OS Evolved Differences in TWAMP Support
The Junos OS Evolved support for TWAMP is limited to the following:
-
IPv4 and IPv6 traffic only for control sessions and test sessions. Starting in Junos OS Evolved Release 21.4R1, IPv6 source and target addresses (except for link-local addresses) are supported for client lists, control connections, and test sessions.
-
Probe statistics and history
-
Control and test session status
-
Test session probe generation and reception, as well as reflection
Timestamps set by the Routing Engine or the Packet Forwarding Engine for IPv4 traffic. For IPv6 traffic, timestamps set by the Routing Engine only. For IPv6 traffic, starting in Junos OS Evolved 22.3R1, we support Packet Forwarding Engine timestamps. Prior to Junos OS Evolved Release 22.3R1, for IPv6 traffic, the
Starting in Junos OS Evolved Release 23.4R1 for servers, the default for theoffload-type
statement at the[edit services monitoring twamp client control-connection name test-session name]
hierarchy level should be configured asnone
. Starting in Junos OS Evolved Release 22.4R1 for supported devices, you can configure theinline-timestamping
option of theoffload-type
statement to enable timestamps set inline by the hardware.offload-type
statement is nowpfe-timestamp
instead ofinline-timestamp
.-
Error reporting through system log messages and SNMP traps only
-
Unauthenticated mode only
Junos OS Evolved support for TWAMP also includes some features that are not included in Junos OS:
-
Starting in Junos OS Evolved Release 23.4R1, we support RFC 8762, Simple Two-Way Active Measurement Protocol (STAMP). RFC 8762 standardizes and expands upon the TWAMP Light operational mode, which was defined in Appendix I of RFC 5357, Two-Way Active Measurement Protocol (TWAMP). For more information, see Simple Two-Way Active Measurement Protocol (STAMP) Support.
-
Starting in Junos OS Evolved Release 24,4R1, we support static route tracking using TWAMP, for those devices that support this feature. See Static Route Tracking for more information.
-
Starting in Junos OS Evolved Release 24.4R1, for those PTX routers that support it, we have added support in Two-Way Active Measurement Protocol (TWAMP) for segment routing (SR) as defined in RFC 8402. See Segment Routing Support for Configuring Paths for more information.
Platform-Specific TWAMP Behavior
Use Feature Explorer: Two-Way Active Measurement Protocol to confirm platform and release support for specific features.
Use the following table to review platform-specific behaviors for your platform.
Platform | Difference |
---|---|
ACX Series |
|
EX Series |
Both the control client and session sender (the TWAMP client) reside on the same Juniper Networks router. However, the TWAMP client does not require that the server and the session reflector to be on the same system. Therefore, the Juniper TWAMP client is capable of working with a third-party server implementation. |
MX Series |
|
PTX Series |
|
QFX 10000 Series |
Both the control client and session sender (the TWAMP client) reside on the same Juniper Networks router. However, the TWAMP client does not require that the server and the session reflector to be on the same system. Therefore, the Juniper TWAMP client is capable of working with a third-party server implementation. |
QFX5000 Series (Junos OS Evolved) |
For Junos OS Evolved, TWAMP is configured at the |
SRX Series (SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100, and SRX4200 devices and vSRX Virtual Firewall instances) |
|
For the MX Series, the table below shows the relationship between RPM client and server support, TWAMP client (with the control component) and TWAMP server (with the responder component) support, and the hardware that performs timestamping.
TWAMP Feature Support |
Routing Engine Timestamp |
MS-PIC/MS-DPC Timestamp |
MS-MIC/MS-MPC Timestamp |
Packet Forwarding Engine (microkernel) Timestamp |
Packet Forwarding Engine (LU) Timestamp ( |
RPM Client |
Yes |
Yes |
Yes |
Yes |
No |
RPM Server |
Yes |
Yes |
Yes |
Yes |
No |
TWAMP Client |
No |
No |
No |
Yes |
Yes |
TWAMP Server |
No |
Yes |
No |
Yes (No responder configuration needed) |
Yes |
Support for the services interfaces (sp-
, ms-
,
and si-
interfaces) are all slightly different.
Table 3 provides information about MX Series TWAMP and related timestamp support on MPC, MS-MIC/MPC, and inline:
Feature |
Role |
IP Version |
Support (Y/N) |
Timestamp Inline |
Timestamp on MPC (hardware-timestamp) |
Timestamp on MPC (si-interface) |
Timestamp on MS-MIC/MPC (delegate-probes) |
---|---|---|---|---|---|---|---|
TWAMP |
Client |
IPv4 |
Y |
N |
Y (µsec) 500 maximum probes |
Y (µsec) 500 maximum probes |
N |
IPv6 |
N |
N |
N |
N |
N |
||
Server |
IPv4 |
Y |
N |
Y (µsec) 500 maximum probes |
Y (µsec) 500 maximum probes |
N |
|
IPv6 |
N |
N |
N |
N |
N |