- 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
Understanding Inline Video Monitoring on MX Series Routers
Junos OS supports inline video monitoring using media delivery index (MDI) metrics.
Before you use the inline video monitoring feature, ensure that you understand the following terms:
media delivery index—MDI metrics facilitate identification of buffering needs for streaming media. Buffering must be adequate to compensate for packet jitter, measured by the MDI delay factor, and quality problems indicated by lost packets, measured by the MDI media loss rate (MLR). By performing measurements under varying load conditions, you can identify sources of significant jitter or packet loss and take appropriate action.
delay factor—Delay factor is the maximum observed time difference between the arrival of media data and the drain of media data. The expected drain rate is the nominal, constant traffic rate for constant bit rate streams or the computed traffic rate of variable rate media stream packet data.
For typical stream rates of 1 megabit per second and higher, an interval of one second provides an adequate sample time. The delay factor indicates how long a data stream must be buffered (delayed) at its nominal bit rate to prevent packet loss.
The delay factor suggests the minimum size of the buffer required at the next downstream node. As a stream progresses, the variation of the delay factor indicates packet bunching or packet gaps (jitter). Greater delay factor values also indicate that more network latency is needed to deliver a stream due to the need to pre-fill a receive buffer before beginning the drain to guarantee no underflow.
When the nominal drain bit rate at a receiving node is known, the delay factor’s maximum indicates the size of buffer required to accommodate packet jitter.
Media rate variation (MRV)—This value is the difference between the expected packet rate and actual packet rate, expressed as a percentage of the expected packet rate.
Media loss rate (MLR)—This value is the number of media packets lost over a configurable time interval (
interval-duration
), where the flow packets carry streaming application information. A single IP packet can contain one or more streaming packets. For example, an IP packet typically contains seven 188-byte MPEG transport stream packets. In this case, a single IP packet loss results in seven lost packets counted (if those seven lost packets did not include null packets). Including out-of-order packets is important, because many consumer-type streaming devices do not attempt to reorder packets that are received out of order.
To configure the monitoring process, define criteria templates and apply them to the interfaces and flows you want to monitor. Monitoring templates include the following criteria:
Duration of each measurement cycle
Flow rate information used to establish expected flow rates
Threshold levels for delay factor, media rate variation, and media loss rate that trigger desired system log alerts
For each interface you want to monitor, you can define one or more filters to select IPv4 flows for monitoring. Flows are designated as input or output flows. Starting in Junos OS Release 17.2R1, you can identify IPv4-over-MPLS flows. Starting in Junos OS Release 17.4R1, you can identify IPv6 flows and IPv6-over MPLS flows. Starting in Junos OS Release 19.1R1, you can configure MX Series routers for inline video monitoring of uncompressed HD or 4K stream video (Payload Type 98 and 99). MDI functionality has been extended to video flows such as ST 2000-5 (RTP PT 98) and ST 2000-6 (RTP PT 99). These are non-MPEG video flows over IP/UDP/RTP and are constant bit-rate flows. The operator would specify proper IP addresses and UDP ports so that non-video flows over RTP will not go through MDI processing.
MPLS flows with more than three labels cannot be monitored.
IPv4 flows are uniquely identified by:
Destination IP address
Destination port
Source IP address
Source port
Direction
Interface index
Media type (RTP or MPEG)
IPv4-over-MPLS flows are uniquely identified by:
The top three MPLS labels
Destination IP address
Destination port
Source IP address
Source port
Direction
Interface index
Media type (RTP or MPEG)
IPv6 flows are uniquely identified by:
Destination IP address
Destination port
Source IP address
Source port
Direction
Interface index
Media type (RTP or MPEG)
IPv6-over-MPLS flows are uniquely identified by:
The top three MPLS labels
Destination IP address
Destination port
Source IP address
Source port
Direction
Interface index
Media type (RTP or MPEG)
Junos OS supports the definition of filters for up to 256 flows on an interface, which can consist of input flows, output flows, or a combination of input and output flows. These filters provide criteria for selecting flows for monitoring. If the selection criteria consist of lists of IP addresses or ports, you can exceed the maximum number of match conditions for flows. Video monitoring selects a widely variable number of flows based on flow filters.
The total number of destination IP addresses configured in a flow for an interface cannot exceed 32, and the total number of source IP addresses configured in a flow for an interface cannot exceed 32.
Inline video monitoring is not supported when you enable Next Gen Services on an MX Series router.
Inline video monitoring is available on MX Series 5G Universal Routing Platforms using only the following MPCs:
MPC1
MPC1E
MPC2
MPC2E
MPC2E-NG
MPC3E-NG
MPC-16XGE
MPC5E
MPC6E
MPC7E
MPC8E
MPC9E
MPC10E
MPC11E
Traffic throughput is reduced below the interface bandwidth when video monitoring is used with an MPC2E-NG or MPC3E-NG in the following scenario:
The input and output ports are on the same slot.
The input-flows is configured as inet and the output-flows is configured as mpls.
At least one flow has a traffic rate greater than 2 Gbps.
To avoid this reduced throughput, use input and output ports on different slots.
Starting in Junos OS Release 16.1R1, you can configure the number of flows that can be measured per Packet Forwarding Engine at a time, up to a value of 8192. The maximum configured number of flows that can be measured for each MPC model is shown in the second column of Table 1. The default number of flows that can be measured for each MPC model is shown in the third column of Table 1. In Junos OS Release 15.1 and earlier, you cannot configure the number of flows that can be measured.
When you do not define input or output flow filters for a monitored interface, all flows on the interface are subject to monitoring.
MPC Model | Maximum Configurable Number of Flows Monitored Simultaneously (Starting in Junos OS Release 16.1) | Default Number of Flows Monitored Simultaneously |
---|---|---|
MPC1 | 8000 | 1000 |
MPC1E | 8000 | 1000 |
MPC2 | 16,000 | 2000 |
MPC2E | 16,000 | 2000 |
MPC2E-NG | 8000 | 1000 |
MPC3E-NG | 8000 | 1000 |
MPC-16XGE | 32,000 | 4000 |
MPC5E | 40,000 | 5000 |
MPC6E | 40,000 | 5000 |
MPC7E | 40,000 | 5000 |
MPC8E | 40,000 | 5000 |
MPC9E | 40,000 | 5000 |
MPC10E | 24,000 (starting in Junos OS Release 20.3R1) | 3000 |
MPC11E | 64,000 (starting in Junos OS Release 20.3R1) | 8000 |
Junos OS measures both UDP flows (the default) and RTP flows. Junos OS differentiates media traffic over UDP or RTP by inspecting the first byte in the UDP payload. If the first byte of the UDP payload is 0x47 (MPEG2-TS sync byte), the traffic is treated as media traffic over UDP. Traffic is treated as media traffic over RTP if the version field is 2 and the payload type is 33 in the RTP header. When neither of these criteria are met, the packet is not considered for video monitoring.
Starting in Junos OS Release 15.1R1, MX Series routers support the inline video monitoring to measure media delivery index (MDI) metrics that can be accessed using the SNMP GET operation. Currently, inline MDI can generate only a system log when the computed value is not within the configured range. SNMP is primarily used to monitor alarms raised by the inline video monitoring feature. The alarms are monitored in the network management systems either to troubleshoot the problem or to diagnose degradation in video quality.
You use the video-monitoring
statement at the [edit services]
hierarchy level to specify monitoring criteria
for two key indicators of video traffic problems: delay factor and
media loss rate (MLR), and to apply these metrics to flows on designated
interfaces.
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.