Understanding Two-Way Active Measurement Protocol on Routers
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:
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:
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.
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.
Table 1 provides information about TWAMP and related timestamp support on MPC, MS-MIC/MPC, and Routing Engine:
Table 1: TWAMP and related timestamp support
Timestamp on Routing Engine
Timestamp on MPC (hardware-timestamp)
Timestamp on MPC (si-interface)
Timestamp on MS-MIC/MPC (delegate-probes)
500 maximum probes
500 maximum probes
500 maximum probes
500 maximum probes
TWAMP on MX Series routers
For Junos OS release 15.1, 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.
TWAMP on PTX Series routers
Starting in Junos OS Release 19.2R1, the Two-Way Active Measurement Protocol (TWAMP) is supported 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.
Starting in Junos OS Evolved Release 20.3R1, TWAMP is supported on PTX10003 routers. For Junos OS Evolved, TWAMP is configured at the [edit services monitoring twamp] hierarchy level. The support for TWAMP is limited to the following:
IPv4 traffic only for control sessions 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
Error reporting through system log messages only
Unauthenticated mode only
TWAMP on ACX Series routers
The Two-Way Active Measurement Protocol (TWAMP) defines a standard for measuring IP performance between two devices in a network. You can configure TWAMP on ACX Series routers. ACX Series routers support only the reflector side of TWAMP.
For more information about TWAMP, see RFC 5357, A Two-Way Active Measurement Protocol (TWAMP).
To configure TWAMP properties, include the twamp statement at the [edit services rpm] hierarchy level:
You can specify a number of TWAMP server properties, some of which are optional, by including the server statement at the [edit services rpm twamp] hierarchy level:
To specify the list of allowed control client hosts that can connect to this server, include the client-list statement at the [edit services rpm twamp server] hierarchy level. Each value you include must be a Classless Interdomain Routing (CIDR) address (IP address plus mask) that represents a network of allowed hosts. You can include multiple client lists, each of which can contain a maximum of 64 entries. You must configure at least one client address to enable TWAMP.
ACX Series routers do not support authentication and encryption modes. The value for authentication-mode statement at the [edit services rpm twamp server] hierarchy level must be set to none.
To specify the maximum number of concurrent connections the server can have to client hosts, include the maximum-connections statement at the [edit services rpm twamp server] hierarchy level. The allowed range of values is 1 through 500 and the default value is 64. You can also limit the number of connections the server can make to a particular client host by including the maximum-connections-per-client statement. ACX Series routers supports a maximum of 15 concurrent connections.
To specify the maximum number of sessions the server can have running at one time, include the maximum-sessions statement at the [edit services rpm twamp server] hierarchy level. The allowed range of values is 1 through 500 and the default value is 64. You can also limit the number of sessions the server can have on a single connection by including the maximum-sessions-per-connection statement. ACX Series routers supports a maximum of 15 sessions.
To specify the TWAMP server listening port, include the port statement at the [edit services rpm twamp server] hierarchy level. The range is 1 through 65,535. If a port range is not specified, then the default port 862 is used.
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.