Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Understand Two-Way Active Measurement Protocol

SUMMARY Learn about using Two-Way Active Measurement Protocol (TWAMP) to measure network performance between any two devices in a network.

Benefits of TWAMP

  • TWAMP 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)

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

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

Table 1 provides information about TWAMP and related timestamp support on MPC, MS-MIC/MPC, and inline:

Table 1: TWAMP and related timestamp support

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

TWAMP Light Support

Table 2 provides information about support for TWAMP Light, as defined in Appendix I of RFC 5357, which defines a light version of the TWAMP protocol, 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.

Support for IPv6 target addresses for TWAMP Light test sessions is introduced in Junos OS Release 21.3R1 and as mentioned in the table below.

Support for IPv6 link-local target addresses is introduced in Junos OS Release 21.4R1, for the MX Series and the PTX1000, PTX3000, and PTX5000 routers and in Junos OS Evolved Release 22.3R1, for the ACX7100, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016 routers.

Table 2: TWAMP Light Support
Device Supported In
ACX710 Junos OS Release 22.3R1
ACX5448 Series Junos OS Release 22.3R1
ACX7100 Series Junos OS Evolved Release 21.2R1
ACX7509 Junos OS Evolved Release 22.3R1
MX Series, with LC480, LC2101, LC2103, and MPCs up to and including the MPC9E Junos OS Release 21.1R1 (IPv4), Junos OS Release 21.3R1 (IPv6)
MX Series with the following line cards: LMIC16-BASE, LC9600, MPC10E, and MPC11E
  • IPv4 client: Junos OS Release 21.1R1
  • IPv4 server: Junos OS Release 22.2R1

  • IPv6 client and server: Junos OS Release 22.3R1
PTX Series running Junos OS, with MPCs up to and including the MPC9E Junos OS Release 21.1R1 (IPv4), Junos OS Release 21.3R1 (IPv6)
PTX Series running Junos OS, with MPC10E and MPC11E line cards
  • client: Junos OS Release 21.1R1 (IPv4)
  • server: Junos OS Release 22.2R1 (IPv4)
PTX10001-36MR

  • Junos OS Evolved Release 21.1R1 (IPv4)

  • Junos OS Evolved Release 21.4R1 (IPv6)
PTX10003

  • Junos OS Evolved Release 20.3R1 (IPv4)

  • Junos OS Evolved Release 21.4R1 (IPv6)
PTX10004

  • Junos OS Evolved Release 21.2R1 (IPv4)

  • Junos OS Evolved Release 21.4R1 (IPv6)
PTX10008 and PTX10016 (with the JNP10008-SF3 and either the JNP10K-LC1201 or JNP10K-LC1202-36MR line card)

  • Junos OS Evolved Release 21.1R1 (IPv4)

  • Junos OS Evolved Release 21.4R1 (IPv6)
QFX5130-32CD, QFX5220, and QFX5700 Junos OS Evolved 22.4R1 (IPv4 and IPv6)
QFX10002, QFX10008, and QFX10016 Junos OS Release 21.3R1 (IPv4)
EX9200 Junos OS Release 21.4R1

Simple Two-Way Active Measurement Protocol (STAMP) Support

Table 3 provides information about support for TWAMP Light, as defined in 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). 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 now 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.

Table 3: STAMP Support

Device

Supported In

ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7509

Junos OS Evolved Release 23.4R1

PTX10001-36MR, PTX10003, PTX10004, and PTX10008 and PTX10016 (with the JNP10008-SF3 and either the JNP10K-LC1201 or JNP10K-LC1202-36MR line card)

Junos OS Evolved Release 23.4R1

TWAMP on MX Series Routers, EX9200 Series and QFX10000 Series Switches

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.

Note:

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

TWAMP on PTX Series routers

The TWAMP-Control protocol is used to set up performance measurement sessions between a TWAMP client and a TWAMP server, and the TWAMP-Test protocol is used to send and receive performance measurement probes. 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. Table 4 provides information about support for TWAMP.

Table 4: PTX Series TWAMP Support
Device Supported In
PTX Series running Junos OS Junos OS Release 19.2R1
PTX10001-36MR

  • Junos OS Evolved Release 21.1R1 (IPv4)

  • Junos OS Evolved Release 22.4R1 (IPv6)
PTX10003

  • Junos OS Evolved Release 20.3R1 (IPv4)

  • Junos OS Evolved Release 22.4R1 (IPv6)
PTX10004

  • Junos OS Evolved Release 21.2R1 (IPv4)

  • Junos OS Evolved Release 22.4R1 (IPv6)
PTX10008 (with the JNP10008-SF3 and either the JNP10K-LC1201 or JNP10K-LC1202-36MR line card)

  • Junos OS Evolved Release 21.1R1 (IPv4)

  • Junos OS Evolved Release 22.4R1 (IPv6)
PTX10016 (with the JNP10008-SF3 and either the JNP10K-LC1201 or JNP10K-LC1202-36MR line card)

Junos OS Evolved Release 22.4R1 (IPv4 and IPv6)

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

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

  • Error reporting through system log messages and SNMP traps only

  • Unauthenticated mode only

TWAMP on QFX5000 Series switches

The TWAMP-Control protocol is used to set up performance measurement sessions between a TWAMP client and a TWAMP server, and the TWAMP-Test protocol is used to send and receive performance measurement probes. For Junos OS Evolved, TWAMP is configured at the [edit services monitoring twamp] hierarchy level.

Table 5: QFX5000 Series TWAMP Support
Device Supported In
QFX5130-32CD Junos OS Evolved Release 22.4R1
QFX5220 Junos OS Evolved Release 22.4R1
QFX5700 Junos OS Evolved Release 22.4R1

The Junos OS Evolved support for TWAMP is limited to the following:

  • IPv4 and IPv6 source and target addresses (including 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 by the Packet Forwarding Engine for IPv4 and IPv6 traffic.

  • Error reporting through system log messages and SNMP traps only

  • Unauthenticated mode only

TWAMP on SRX Series Firewalls

SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100, and SRX4200 devices and vSRX Virtual Firewall instances have the following limitations for TWAMP support:

  • TWAMP for IPv6 is not supported.

  • TWAMP server and TWAMP client authentication are not supported.

  • TWAMP Light is not supported.

TWAMP on ACX Series routers

In Junos OS, TWAMP is supported for ACX routers. The ACX710 and ACX5448 Series routers support both reflection and generation. Other ACX Series routers running Junos OS support only reflection, not generation. For Junos OS, TWAMP is configured at the [edit services rpm twamp] hierarchy level.

In Junos OS Evolved, TWAMP is supported for ACX routers, for both reflection and generation. Starting in Junos OS Evolved 21.2R1, TWAMP (including TWAMP Light) is supported for the ACX7100 Series routers. For Junos OS Evolved, TWAMP is configured at the [edit services monitoring twamp] hierarchy level. The Junos OS Evolved support for TWAMP is limited to the following:

  • IPv4 traffic only for control sessions and test sessions; IPv6 traffic support (except for link-local addresses) starting in Junos OS Evolved Release 21.4R1. Support for IPv6 link-local addresses for TWAMP Light test sessions only starting in Junos OS Evolved 22.3R1.

  • 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 22.4R1 for ACX routers, 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 23.4R1, the default for the offload-type statement is now pfe-timestamp instead of inline-timestamp.

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

  • Error reporting through system log messages only

  • Unauthenticated mode only

Related Documentation