- 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 Real-Time Performance Monitoring and Video Monitoring Services
- play_arrow Monitoring Traffic Using Real-Time Performance Monitoring and Two-Way Active Monitoring Protocol (TWAMP)
- Understanding Using Probes for Real-Time Performance Monitoring on M, T, ACX, MX, and PTX Series Routers, EX and QFX Switches
- Configuring RPM Probes on M, MX and T Series Routers and EX Series Switches
- Understanding Real-Time Performance Monitoring on EX and QFX Switches
- Real-Time Performance Monitoring for SRX Devices
- Configuring RPM Receiver Servers
- Limiting the Number of Concurrent RPM Probes on M, MX, T and PTX Routers and EX Series Switches
- Configuring RPM Timestamping on MX, M, T, and PTX Series Routers and EX Series Switches
- Configuring the Interface for RPM Timestamping for Client/Server on a Switch (EX Series)
- Analyzing Network Efficiency in IPv6 Networks on MX Series Routers Using RPM Probes
- Configuring BGP Neighbor Discovery Through RPM
- Examples: Configuring BGP Neighbor Discovery on SRX Series Firewalls and MX, M, T and PTX Series Routers With RPM
- Trace RPM Operations
- Examples: Configuring Real-Time Performance Monitoring on MX, M, T and PTX Series Routers
- Enabling RPM on MX, M and T Series Routers and SRX Firewalls for the Services SDK
- Understand Two-Way Active Measurement Protocol
- Configure TWAMP on ACX, MX, M, T, and PTX Series Routers, EX Series and QFX10000 Series Switches
- Example: Configuring TWAMP Client and Server on MX Series Routers
- Example: Configuring TWAMP Client and Server for SRX Series Firewalls
- Understanding TWAMP Auto-Restart
- Configuring TWAMP Client and TWAMP Server to Reconnect Automatically After TWAMP Server Unavailability
- play_arrow Managing License Server for Throughput Data Export
- play_arrow Testing the Performance of Network Devices Using RFC 2544-Based Benchmarking
- Understanding RFC 2544-Based Benchmarking Tests on MX Series Routers and SRX Series Firewalls
- Understanding RFC2544-Based Benchmarking Tests for E-LAN and E-Line Services on MX Series Routers
- Supported RFC 2544-Based Benchmarking Statements on MX Series Routers
- Configuring an RFC 2544-Based Benchmarking Test
- Enabling Support for RFC 2544-Based Benchmarking Tests on MX Series Routers
- Example: Configure an RFC 2544-Based Benchmarking Test on an MX104 Router for Layer 3 IPv4 Services
- Example: Configuring an RFC 2544-Based Benchmarking Test on an MX104 Router for UNI Direction of Ethernet Pseudowires
- Example: Configuring an RFC 2544-Based Benchmarking Test on an MX104 Router for NNI Direction of Ethernet Pseudowires
- Example: Configuring RFC2544-Based Benchmarking Tests on an MX104 Router for Layer 2 E-LAN Services in Bridge Domains
- Example: Configuring Benchmarking Tests to Measure SLA Parameters for E-LAN Services on an MX104 Router Using VPLS
- play_arrow Configuring RFC 2544-Based Benchmarking Tests on ACX Series
- RFC 2544-Based Benchmarking Tests for ACX Routers Overview
- Layer 2 and Layer 3 RFC 2544-Based Benchmarking Test Overview
- Configuring RFC 2544-Based Benchmarking Tests
- Configuring Ethernet Loopback for RFC 2544-Based Benchmarking Tests
- RFC 2544-Based Benchmarking Test States
- Example: Configure an RFC 2544-Based Benchmarking Test for Layer 3 IPv4 Services
- Example: Configuring an RFC 2544-Based Benchmarking Test for NNI Direction of Ethernet Pseudowires
- Example: Configuring an RFC 2544-Based Benchmarking Test for UNI Direction of Ethernet Pseudowires
- Configuring a Service Package to be Used in Conjunction with PTP
- play_arrow Tracking Streaming Media Traffic Using Inline Video Monitoring
- Understanding Inline Video Monitoring on MX Series Routers
- Configuring Inline Video Monitoring on MX Series Routers
- Inline Video Monitoring Syslog Messages on MX Series Routers
- Generation of SNMP Traps and Alarms for Inline Video Monitoring on MX Series Routers
- SNMP Traps for Inline Video Monitoring Statistics on MX Series Routers
- Processing SNMP GET Requests for MDI Metrics on MX Series Routers
-
- play_arrow Configuration Statements and Operational Commands
Example: Configuring Flow Collection
Figure 1 shows the path traveled by monitored traffic as it passes through the router. Packets arrive at input interfaces so-0/1/0, so-3/0/0, and so-3/1/0. The raw packets are directed into a filter-based forwarding routing instance and processed into cflowd records by the monitoring services interfaces mo-7/1/0, mo-7/2/0, and mo-7/3/0. The cflowd records are compressed into files at the flow collector interfaces cp-6/0/0 and cp-7/0/0 and sent to the FTP server for analysis. Finally, a mandatory class-of-service (CoS) configuration is applied to export channels 0 and 1 on the flow collector interfaces to manage the outgoing processed files.

[edit] chassis { fpc 6 { pic 0 { monitoring-services { application flow-collector; # This converts a Monitoring Services II or # Multiservices 400 PIC into a flow collector interface. } } } fpc 7 { pic 0 { monitoring-services { application flow-collector; # This converts a Monitoring Services II or # Multiservices 400 PIC into a flow collector interface. } } } } interfaces { cp-6/0/0 { unit 0 { # Logical interface .0 on a flow collector interface is export family inet { # channel 0 and sends records to the FTP server. filter { output cp-ftp; # Apply the CoS filter here. } address 10.0.0.1/32 { destination 10.0.0.2; } } } unit 1 { # Logical interface .1 on a flow collector interface is export family inet {# channel 1 and sends records to the FTP server. filter { output cp-ftp; # Apply the CoS filter here. } address 10.1.1.1/32 { destination 10.1.1.2; } } } unit 2 { # Logical interface .2 on a flow collector interface is the flow family inet { # receive channel that communicates with the Routing Engine. address 10.2.2.1/32 { # Do not apply a CoS filter on logical interface .2. destination 10.2.2.2; } } } } cp-7/0/0 { unit 0 {# Logical interface .0 on a flow collector interface is export family inet {# channel 0 and sends records to the FTP server. filter { output cp-ftp;# Apply the CoS filter here. } address 10.3.3.1/32 { destination 10.3.3.2; } } } unit 1 {# Logical interface .1 on a flow collector interface is export family inet {# channel 1 and sends records to the FTP server. filter { output cp-ftp;# Apply the CoS filter here. } address 10.4.4.1/32 { destination 10.4.4.2; } } } unit 2 {# Logical interface .2 on a flow collector interface is the flow family inet {# receive channel that communicates with the Routing Engine. address 10.5.5.1/32 {# Do not apply a CoS filter on logical interface .2. destination 10.5.5.2; } } } } fe-1/3/0 { # This is the exit interface leading to the first FTP server. unit 0 { family inet { address 192.168.56.90/30; } } } ge-1/0/0 { # This is the exit interface leading to the second FTP server. unit 0 { family inet { address 192.168.252.2/24; } } } mo-7/1/0 { # This is the first interface that creates cflowd records. unit 0 { family inet; } } mo-7/2/0 { # This is the second interface that creates cflowd records. unit 0 { family inet; } } mo-7/3/0 { # This is the third interface that creates cflowd records. unit 0 { family inet; } } so-0/1/0 { # This is the first input interface that receives traffic to be monitored. encapsulation ppp; unit 0 { passive-monitor-mode; # This allows the interface to be passively monitored. family inet { filter { input catch; # The filter-based forwarding filter is applied here. } } } } so-3/0/0 { # This is the second interface that receives traffic to be monitored. encapsulation ppp; unit 0 { passive-monitor-mode; # This allows the interface to be passively monitored. family inet { filter { input catch; # The filter-based forwarding filter is applied here. } } } } so-3/1/0 { # This is the third interface that receives traffic to be monitored. encapsulation ppp; unit 0 { passive-monitor-mode; # This allows the interface to be passively monitored. family inet { filter { input catch; # The filter-based forwarding filter is applied here. } } } } forwarding-options { monitoring group1 {# Always define your monitoring group here. family inet { output { export-format cflowd-version-5; flow-active-timeout 60; flow-inactive-timeout 15; flow-export-destination collector-pic; # Sends records to the flow collector. interface mo-7/1/0.0 { source-address 192.168.252.2; } interface mo-7/2/0.0 { source-address 192.168.252.2; } interface mo-7/3/0.0 { source-address 192.168.252.2; } } } } firewall { family inet { filter cp-ftp { # This filter provides CoS for flow collector interface traffic. term t1 { then forwarding-class expedited-forwarding; } } } filter catch { # This firewall filter sends incoming traffic into the interface-specific;# filter-based forwarding routing instance. term def { then { count counter; routing-instance fbf_instance; } } } } routing-options { interface-routes { rib-group inet common; } rib-groups { common { import-rib [inet.0 fbf_instance.inet.0]; } } forwarding-table { export pplb; } } policy-options { policy-statement pplb { then { load-balance per-packet; } } } routing-instances { fbf_instance { # This instance sends traffic to the monitoring services interface. instance-type forwarding; routing-options { static { route 0.0.0.0/0 next-hop mo-7/1/0.0; } } } } class-of-service { # A class-of-service configuration for the flow collector interface interfaces { # is required for flow collector services. cp-6/0/0 { scheduler-map cp-map; } cp-7/0/0 { scheduler-map cp-map; } } } scheduler-maps { cp-map { forwarding-class best-effort scheduler Q0; forwarding-class expedited-forwarding scheduler Q1; forwarding-class network-control scheduler Q3; } } schedulers { Q0 { transmit-rate remainder; buffer-size percent 90; } Q1 { transmit-rate percent 5; buffer-size percent 5; priority strict-high; } Q3 { transmit-rate percent 5; buffer-size percent 5; } } services { flow-collector { # Define properties for flow collector interfaces here. analyzer-address 10.10.10.1; # This is the IP address of the analyzer. analyzer-id server1; # This helps to identify the analyzer. retry 3; # Maximum number of attempts by the PIC to send a file transfer log. retry-delay 30; # The time interval between attempts to send a file transfer log. destinations { # This defines the FTP servers that receive flow collector output. "ftp://user@192.168.56.89//tmp/collect1/" { # The primary FTP server. password "$ABC123"; # SECRET-DATA } "ftp://user@192.168.252.1//tmp/collect2/" { # The secondary FTP server. password "$ABC123"; # SECRET-DATA } } file-specification { # Define sets of flow collector characteristics here. def-spec { name-format "default-allInt-0-%D_%T-%I_%N.bcp.bi.gz"; data-format flow-compressed; # The default compressed output format. } # When no overrides are specified, a collector uses default transfer values. f1 { name-format "cFlowd-py69Ni69-0-%D_%T-%I_%N.bcp.bi.gz"; data-format flow-compressed; # The default compressed output format. transfer timeout 1800 record-level 1000000; # Here are configured values. } } interface-map { # Allows you to map interfaces to flow collector interfaces. file-specification def-spec; # Flows generated for default traffic are sent to the collector cp-7/0/0; # default flow collector interface "cp-7/0/0". so-0/1/0.0 { # Flows generated for the so-0/1/0 interface are sent collector cp-6/0/0; # to cp-6/0/0, and the file-specification used is } # "default." so-3/0/0.0 { # Flows generated for the so-3/0/0 interface are sent file-specification f1; # to cp-6/0/0, and the file-specification used is "f1." collector cp-6/0/0; } so-3/1/0.0; # Because no settings are defined, flows generated for this } # interface use interface cp-7/0/0 and the default file specification. transfer-log-archive { # Sends flow collector interface log files to an FTP server. filename-prefix so_3_0_0_log; maximum-age 15; archive-sites { "ftp://user@192.168.56.89//tmp/transfers/" { password "$ABC123"; } } ] } }