- 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
Configure TWAMP
The Two-Way Active Measurement Protocol (TWAMP) defines a standard for measuring IP performance between two devices in a network. For more information on TWAMP, see RFC 5357, A Two-Way Active Measurement Protocol (TWAMP). For more background information on TWAMP, see Understand Two-Way Active Measurement Protocol.
Understand TWAMP Configuration
Two-Way Active Measurement Protocol (TWAMP) support and configuration varies for hardware platform, physical interfaces, or virtual physical (services) interfaces. Support for RPM is not always an indicator of TWAMP support on a particular combination of platform and line card for Junos OS. The time stamps used in RPM and TWAMP are added in different places, depending on the hardware configuration. For example, different hardware components perform timestamping, either inline in the lookup (LU) chip, Routing Engine (Junos OS Evolved), the microkernel-based timestamping at the host Packet Forwarding Engine, or the line card such as a Multiservices Physical Interface Card (MS-PIC), Multiservices Modular Interface Card (MS-MIC), Multiservices Modular PIC Concentrator (MS-MPC), or Multiservices Dense Port Concentrator (MS-DPC).
Use Feature Explorer: Two-Way Active Measurement Protocol to confirm platform and release support for specific features.
See Understand Two-Way Active Measurement Protocol for Junos OS Evolved differences and notes about your platform.
- TWAMP Light Support
- Simple Two-Way Active Measurement Protocol (STAMP) Support
- TWAMP Managed Support
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.
Support for IPv6 target addresses for TWAMP Light test sessions is introduced in
Junos OS Release
21.3R1.
For the Junos OS IPv6 TWAMP Light client, you must configure both the
target-address
and the destination-port
statements at the [edit services rpm twamp client control-connection
control-client-name test-session
test-session-name]
hierarchy level. Support
for link-local target addresses for IPv6 TWAMP Light test sessions is introduced
starting
in Junos OS Release
21.4R1
and in Junos OS Evolved Release 22.3R1, for
those devices
that support TWAMP
Light.
Simple Two-Way Active Measurement Protocol (STAMP) Support
STAMP,
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). 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
.
Use Feature Explorer: Simple Two-Way Active Measurement Protocol (STAMP) to confirm platform and release support.
TWAMP Managed 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.
Use Two-Way Active Measurement Protocol to confirm platform and release support for specific features.
Configure a TWAMP Server
With the exception of physical interfaces, TWAMP server configuration for Junos
OS requires the following minimum configuration at the [edit services
rpm twamp
] hierarchy level:
server { authentication-mode mode; client-list list-name { address ip-address; } port 862; }
Starting in Junos OS Release 21.3R1, you no longer need to configure the
authentication-mode
statement. The default mode is now
none
, which means that communications with the server are
not authenticated.
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 tonone
.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.
Configure TWAMP provides information about support for light control of the server.
For Junos OS, you can configure light control for the server (managed control is
the default). The Junos OS TWAMP server configuration for light control requires
the following minimum configuration at the [edit services rpm
twamp]
hierarchy level:
server { authentication-mode none; light; port (862 | 878 | 51000); }
For Junos OS, for a list of restrictions on source addresses, see source-address (TWAMP).
For Junos OS Evolved, you can configure
either managed or light control for the server. TWAMP server configuration for
managed or light control requires the following minimum configuration at the
[edit services monitoring twamp]
hierarchy level, assuming
you use the default port for TWAMP (862):
For Junos OS Evolved, you cannot use the following addresses for the client-list source IP address used for probes:
0.0.0.0
127.0.0.0/8 (loopback)
224.0.0.0/4 (multicast)
255.255.255.255 (broadcast)
You can configure more than one client, and you can change the TWAMP listening port as long as the change is coordinated with the TWAMP client.
For microkernel-based timestamping in Junos OS, you don’t need to configure an
si-
interface. In this case, the TWAMP connection and
sessions are established based on the target address and route.
For inline timestamping in Junos OS, you need to configure si-
or sp-
services interfaces and theTWAMP server configuration
requires the following statements at the [edit interfaces
service-interface-name]
hierarchy level:
user@router# show interfaces si-0/0/0 unit 10 { rpm twamp-server; family inet { address 10.10.10.1/24; } }
user@router# show interfaces sp-0/0/0 unit 10 { rpm twamp-server; family inet { address 10.20.20.1/24; } }
You cannot configure the TWAMP server on unit 0 of a services interface. If you try, you will receive a configuration error.
(Junos OS only) To configure a TWAMP server on an inline services
(si-
) interface, configure the amount of bandwidth reserved
on each Packet Forwarding Engine for tunnel traffic using inline services by
including the bandwidth (1g | 10g)
statement at the
[edit chassis fpc slot-number pic number inline-services]
hierarchy level. Specify the service PIC (sp-
) logical
interface that provides the TWAMP service by including the
twamp-server
statement at the [edit interfaces
sp-fpc/pic/port unit
logical-unit-number family inet]
hierarchy
level.
The twamp-server
statement is not required for physical
interface TWAMP server configuration.
Many other TWAMP server parameters are optional. See the TWAMP
server
configuration statements for details.
Configure a TWAMP Client
For Junos OS, to configure the TWAMP client service, include the client
statement and related parameters at the [edit services rpm
twamp]
hierarchy level. For Junos OS Evolved, include the client
statement and related options at the [edit services monitoring
twamp
] hierarchy level.
There are many options available for TWAMP client configuration. See the configuration statement topics and examples for details.
For microkernel-based timestamping in Junos OS, you don’t need to configure an
si-
interface. In this case, the TWAMP connection and
sessions are established based on the target address and route.
For inline timestamping in Junos OS, the si-
interfaces are
virtual physical interfaces that respond as a TWAMP server. However, you can
also configure services interfaces to act as the TWAMP client, which performs
the TWAMP controller role.
(Junos OS only) To configure a services interface as a TWAMP client, you configure the service parameters and the service interface as a TWAMP client.
To configure the TWAMP client services interface, include the rpm
twamp-client
statement at the [edit interfaces
si-interface-name]
hierarchy level:
user@router# show interfaces si-0/0/0 unit 0 { family inet; } unit 10 { rpm twamp-client; family inet { address 10.30.30.1/24 } }
You cannot configure the TWAMP client on unit 0 of a service interface. If you try, you will receive a configuration error.
See Also
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
offload-type
statement is now
pfe-timestamp
instead of inline-timestamp
.
authentication-mode
statement for the TWAMP server. The
default mode is none
.