- play_arrow Flow Monitoring and Flow Collection Services
- play_arrow Understanding Flow Monitoring
- play_arrow Monitoring Traffic Using Active Flow Monitoring
- Configuring Active Flow Monitoring
- Active Flow Monitoring System Requirements
- Active Flow Monitoring Applications
- Active Flow Monitoring PIC Specifications
- Active Flow Monitoring Overview
- Active Flow Monitoring Overview
- Example: Configuring Active Monitoring on an M, MX or T Series Router’s Logical System
- Example: Configuring Flow Monitoring on an MX Series Router with MS-MIC and MS-MPC
- Configuring Services Interface Redundancy with Flow Monitoring
- Configuring Inline Active Flow Monitoring Using Routers, Switches or NFX250
- Configuring Flow Offloading on MX Series Routers
- Configuring Active Flow Monitoring on PTX Series Packet Transport Routers
- Configuring Actively Monitored Interfaces on M, MX and T Series Routers
- Collecting Flow Records
- Configuring M, MX and T Series Routers for Discard Accounting with an Accounting Group
- Configuring M, MX and T Series Routers for Discard Accounting with a Sampling Group
- Configuring M, MX and T Series Routers for Discard Accounting with a Template
- Defining a Firewall Filter on M, MX and T Series Routers to Select Traffic for Active Flow Monitoring
- Processing IPv4 traffic on an M, MX or T Series Router Using Monitoring services, Adaptive services or Multiservices Interfaces
- Replicating M, MX and T Series Routing Engine-Based Sampling to Multiple Flow Servers
- Replicating Version 9 Flow Aggregation From M, MX and T Series Routers to Multiple Flow Servers
- Configuring Routing Engine-Based Sampling on M, MX and T Series Routers for Export to Multiple Flow Servers
- Example: Copying Traffic to a PIC While an M, MX or T Series Router Forwards the Packet to the Original Destination
- Configuring an Aggregate Export Timer on M, MX and T Series Routers for Version 8 Records
- Example: Sampling Configuration for M, MX and T Series Routers
- Associating Sampling Instances for Active Flow Monitoring with a Specific FPC, MPC, or DPC
- Example: Sampling Instance Configuration
- Example: Sampling and Discard Accounting Configuration on M, MX and T Series Routers
- play_arrow Monitoring Traffic Using Passive Flow Monitoring
- Passive Flow Monitoring Overview
- Passive Flow Monitoring System Requirements for T Series, M Series and MX Series Routers
- Passive Flow Monitoring Router and Software Considerations for T Series, M Series and MX Series Routers
- Understanding Passive Flow Monitoring on T Series, M Series and MX Series Routers
- Enabling Passive Flow Monitoring on M Series, MX Series or T Series Routers
- Configuring Passive Flow Monitoring
- Example: Passive Flow Monitoring Configuration on M, MX and T Series Routers
- Configuring a Routing Table Group on an M, MX or T Series Router to Add Interface Routes into the Forwarding Instance
- Using IPSec and an ES PIC on an M, MX or T Series Router to Send Encrypted Traffic to a Packet Analyzer
- Applying a Firewall Filter Output Interface on an M, MX or T Series Router to Port-mirror Traffic to PICs or Flow Collection Services
- Monitoring Traffic on a Router with a VRF Instance and a Monitoring Group
- Specifying a Firewall Filter on an M, MX or T Series Router to Select Traffic to Monitor
- Configuring Input Interfaces, Monitoring Services Interfaces and Export Interfaces on M, MX or T Series Routers
- Establishing a VRF Instance on an M, MX or T Series Router for Monitored Traffic
- Configuring a Monitoring Group on an M, MX or T Series Router to Send Traffic to the Flow Server
- Configuring Policy Options on M, MX or T Series Routers
- Stripping MPLS Labels on ATM, Ethernet-Based and SONET/SDH Router Interfaces
- Using an M, MX or T Series Router Flow Collector Interface to Process and Export Multiple Flow Records
- Example: Configuring a Flow Collector Interface on an M, MX or T Series Router
- play_arrow Processing and Exporting Multiple Records Using Flow Collection
- play_arrow Logging Flow Monitoring Records with Version 9 and IPFIX Templates for NAT Events
- Understanding NAT Event Logging in Flow Monitoring Format on an MX Series Router or NFX250
- Configure Active Flow Monitoring Logs for NAT44/NAT64
- Configuring Log Generation of NAT Events in Flow Monitoring Record Format on an MX Series Router or NFX250
- Exporting Syslog Messages to an External Host Without Flow Monitoring Formats Using an MX Series Router or NFX250
- Exporting Version 9 Flow Data Records to a Log Collector Overview Using an MX Series Router or NFX250
- Understanding Exporting IPFIX Flow Data Records to a Log Collector Using an MX Series Router or NFX250
- Mapping Between Field Values for Version 9 Flow Templates and Logs Exported From an MX-Series Router or NFX250
- Mapping Between Field Values for IPFIX Flow Templates and Logs Exported From an MX Series Router or NFX250
- Monitoring NAT Events on MX Series Routers by Logging NAT Operations in Flow Template Formats
- Example: Configuring Logs in Flow Monitoring Format for NAT Events on MX Series Routers for Troubleshooting
-
- play_arrow Flow Capture Services
- play_arrow Dynamically Capturing Packet Flows Using Junos Capture Vision
- play_arrow Detecting Threats and Intercepting Flows Using Junos Flow-Tap and FlowTapLite Services
- Understanding the FlowTap and FlowTapLite Services
- Understanding FlowTap and FlowTapLite Architecture
- Configuring the FlowTap Service on MX Series Routers
- Configuring a FlowTap Interface on MX Series Routers
- Configuring FlowTap and FlowTapLite Security Properties
- FlowTap and FlowTapLite Application Restrictions
- Examples: Configuring the FlowTapLite Application on MX Series and ACX Series Routers
- Configuring FlowTapLite on MX Series Routers and M320 Routers with FPCs
-
- play_arrow Inline Monitoring Services and Inband Network Telemetry
- play_arrow Inline Monitoring Services
- play_arrow Flow-Based Telemetry
- play_arrow Inband Flow Analyzer 2.0
- play_arrow Juniper Resiliency Interface
-
- play_arrow Sampling and Discard Accounting Services
- play_arrow Sampling Data Using Traffic Sampling and Discard Accounting
- play_arrow Sampling Data Using Inline Sampling
- Understand Inline Active Flow Monitoring
- Configuring Inline Active Flow Monitoring Using Routers, Switches or NFX250
- Configuring Inline Active Flow Monitoring on MX80 and MX104 Routers
- Configuring Inline Active Flow Monitoring on PTX Series Routers
- Inline Active Flow Monitoring of MPLS-over-UDP Flows on PTX Series Routers
- Inline Active Flow Monitoring on IRB Interfaces
- Example: Configuring Inline Active Flow Monitoring on MX Series and T4000 Routers
- play_arrow Sampling Data Using Flow Aggregation
- Understanding Flow Aggregation
- Enabling Flow Aggregation
- Configuring Flow Aggregation on MX, M and T Series Routers and NFX250 to Use Version 5 or Version 8 cflowd
- Configuring Flow Aggregation on MX, M, vMX and T Series Routers and NFX250 to Use Version 9 Flow Templates
- Configuring Flow Aggregation on PTX Series Routers to Use Version 9 Flow Templates
- Configuring Inline Active Flow Monitoring to Use IPFIX Flow Templates on MX, vMX and T Series Routers, EX Series Switches, NFX Series Devices, and SRX Series Firewalls
- Configuring Flow Aggregation to Use IPFIX Flow Templates on PTX Series Routers
- Configuring Observation Domain ID and Source ID for Version 9 and IPFIX Flows
- Configuring Template ID and Options Template ID for Version 9 and IPFIX Flows
- Including Fragmentation Identifier and IPv6 Extension Header Elements in IPFIX Templates on MX Series Routers
- Directing Replicated Flows from M and T Series Routers to Multiple Flow Servers
- Logging cflowd Flows on M and T Series Routers Before Export
- Configuring Next-Hop Address Learning on MX Series and PTX Series Routers for Destinations Accessible Over Multiple Paths
-
- play_arrow Configuration Statements and Operational Commands
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-typestatement 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-timestampingoption of theoffload-typestatement to enable timestamps set inline by the hardware.offload-typestatement is nowpfe-timestampinstead 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 |
