Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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.

Note:

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:

Figure 1: Four Elements of TWAMP Four Elements of TWAMP

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.

Figure 2: The Elements of TWAMP Implemented as Client (Left) and Server (Right). The Elements of TWAMP Implemented as Client (Left) and Server (Right).

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 offload-type statement at the [edit services monitoring twamp client control-connection name test-session name] hierarchy level should be configured as none. Starting in Junos OS Evolved Release 22.4R1 for supported devices, you can configure the inline-timestamping option of the offload-type statement to enable timestamps set inline by the hardware.

    Starting in Junos OS Evolved Release 23.4R1 for servers, the default for the offload-type statement is now pfe-timestamp instead of inline-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.

Table 1: Platform-Specific TWAMP Behavior
Platform Difference

ACX Series

  • In Junos OS, the ACX710 and ACX5448 Series routers support both reflection and generation. Other ACX Series routers running Junos OS support only reflection, not generation.

  • In Junos OS Evolved, TWAMP is supported for ACX routers, for both reflection and generation. See Junos OS Evolved Differences in TWAMP Support for notes about OS differences in TWAMP support.

  • For Junos OS, TWAMP is configured at the [edit services rpm twamp] hierarchy level. For Junos OS Evolved, TWAMP is configured at the [edit services monitoring twamp] hierarchy level.

  • TWAMP control connection traffic always arrives on ACX routers with the listening port set as 862. Because this port number for traffic probes can be modified, probes that arrive with a different port number are not recognized and processed by ACX routers correctly. As a result, TWAMP traffic and host-bound packets are dropped in such a scenario.

  • For inline-timestamping mode, The TWAMP client and server cannot be configured on the same ACX router.

  • For inline-timestamping mode, TWAMP over Layer 3 VPN is not supported.

  • Prior to Junos OS Evolved Release 23.4R1, if both TWAMP and connectivity fault management (CFM) are configured, the TWAMP client drops the TWAMP probes. Remove the CFM configuration to enable TWAMP. Starting in Junos OS Evolved Release 23.4R1, you can configure CFM on the same device as TWAMP.

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

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

  • TWAMP is not supported when you enable Next Gen Services on an MX Series router.

PTX Series

  • The destination interface si-x/y/z attribute, which is meant for enabling inline services, is not supported on PTX Series routers for TWAMP client configurations.

  • For Junos OS, TWAMP is configured at the [edit services rpm twamp] hierarchy level. For Junos OS Evolved, TWAMP is configured at the [edit services monitoring twamp] hierarchy level. See Junos OS Evolved Differences in TWAMP Support for notes about OS differences in TWAMP support.

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 [edit services monitoring twamp] hierarchy level. See Junos OS Evolved Differences in TWAMP Support for notes about OS differences in TWAMP support.

SRX Series (SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100, and SRX4200 devices and vSRX Virtual Firewall instances)

  • TWAMP for IPv6 is not supported.

  • TWAMP server and TWAMP client authentication are not supported.

  • TWAMP Light is not supported.

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.

Table 2: TWAMP Feature Support and Hardware for Junos OS, MX Series

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 (si- interface)

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

Note:

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:

Table 3: TWAMP and related timestamp support, MX Series

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