- 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 a Flow Collector Interface on an M, MX or T Series Router

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 flow records by the monitoring services interfaces mo-7/1/0, mo-7/2/0, and mo-7/3/0. The flow 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.
Router 1
[edit] chassis { fpc 6 { pic 0 { monitoring-services { application flow-collector; # This converts a Monitoring Services II PIC } # into a flow collector interface. } } fpc 7 { pic 0 { monitoring-services { application flow-collector; # This converts a Monitoring Services II 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 flow records. unit 0 { family inet; } } mo-7/2/0 { # This is the second interface that creates flow records. unit 0 { family inet; } } mo-7/3/0 { # This is the third interface that creates flow 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; } } } } } 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; } } } class-of-service { # A class-of-service configuration for the flow collector interface interfaces { # is mandatory when implementing 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; } } } 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-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; } } } } 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 second FTP server. password "$ABC123"; # SECRET-DATA } } file-specification { # Define sets of flow collector characteristics here. def-spec { } data-format flow-compressed; # The default compressed output format. } 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 } 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"; } } } }
Verifying Your Work
To verify that your flow collector configuration is working, use the following commands on the monitoring station that is configured for flow collection:
clear services flow-collector statistics
request services flow-collector change-destination (primary | secondary)
request services flow-collector test-file-transfer
show services flow-collector file interface (detail | extensive | terse)
show services flow-collector (detail | extensive)
show services flow-collector input interface (detail | extensive | terse)
The following section shows the output of the show
commands used with the configuration example:
user@router1> show services flow-collector input interface cp-6/0/0 detail Interface Packets Bytes mo-7/1/0.0 6170 8941592 user@router1> show services flow-collector interface all detail Flow collector interface: cp-6/0/0 Interface state: Collecting flows Packets Bytes Flows Uncompressed Compressed FTP bytes FTP files Bytes Bytes 6736 9757936 195993 21855798 3194148 0 0 Flow collector interface: cp-7/0/0 Interface state: Collecting flows Packets Bytes Flows Uncompressed Compressed FTP bytes FTP files Bytes Bytes 0 0 0 0 0 0 0 user@router1> show services flow-collector input interface cp-6/0/0 extensive Interface Packets Bytes mo-7/1/0.0 6260 9074096 user@router1> show services flow-collector interface cp-6/0/0 extensive Flow collector interface: cp-6/0/0 Interface state: Collecting flows Memory: Used: 19593212, Free: 479528656 Input: Packets: 6658, per second: 0, peak per second: 0 Bytes: 9647752, per second: 12655, peak per second: 14311 Flow records processed: 193782, per second: 252, peak per second: 287 Allocation: Blocks allocated: 174, per second: 0, peak per second: 0 Blocks freed: 0, per second: 0, peak per second: 0 Blocks unavailable: 0, per second: 0, peak per second: 0 Files: Files created: 1, per second: 0, peak per second: 0 Files exported: 0, per second: 0, peak per second: 0 Files destroyed: 0, per second: 0, peak per second: 0 Throughput: Uncompressed bytes: 21075152, per second: 52032, peak per second: 156172 Compressed bytes: 3079713, per second: 7618, peak per second: 22999 Packet drops: No memory: 0, Not IP: 0 Not IPv4: 0, Too small: 0 Fragments: 0, ICMP: 0 TCP: 0, Unknown: 0 Not JUNOS flow: 0 File Transfer: FTP bytes: 0, per second: 0, peak per second: 0 FTP files: 0, per second: 0, peak per second: 0 FTP failure: 0 Export channel: 0 Current server: Secondary Primary server state: OK, Secondary server state: OK Export channel: 1 Current server: Secondary Primary server state: OK, Secondary server state: OK user@router1> show services flow-collector file interface cp-6/0/0 terse File name Flows State cFlowd-py69Ni69-0-20031112_014301-so_3_0_0_0.bcp.bi.gz 185643 Active user@router1> show services flow-collector file interface cp-6/0/0 detail Filename: cFlowd-py69Ni69-0-20031112_014301-so_3_0_0_0.bcp.bi.gz Throughput: Flow records: 187067, Uncompressed bytes: 21121960, Compressed bytes: 2965643 Status: State: Active, Transfer attempts: 0 user@router1> show services flow-collector file interface cp-6/0/0 extensive Filename: cFlowd-py69Ni69-0-20031112_014301-so_3_0_0_0.bcp.bi.gz Throughput: Flow records: 188365, per second: 238, peak per second: 287 Uncompressed bytes: 21267756, per second: 27007, peak per second: 32526 Compressed bytes: 2965643, per second: 0, peak per second: 22999 Status: Compressed blocks: 156, Block count: 156 State: Active, Transfer attempts: 0
To clear statistics for a flow collector interface,
issue the clear services flow-collector statistics interface
(all | interface-name)
command.
Another useful flow collector option allows you
to change the FTP server from primary to secondary and test for FTP
transfers. To force the flow collector interface to use a primary
or secondary FTP server, include the primary or secondary option when you issue the request services flow-collector change-destination
interface cp-fpc/pic/port
command.
If you configure only one primary server and issue this command with the primary option, you receive the error message “Destination change not needed.” If the secondary server is not configured and you issue this command with the secondary option, you receive the error message “Destination not configured.” Otherwise, when both servers are configured properly, successful output appears as follows.
user@router1> request services flow-collector change-destination interface cp-6/0/0 primary Flow collector interface: cp-6/0/0 Interface state: Collecting flows Destination change successful user@router1> request services flow-collector change-destination interface cp-6/0/0 secondary Flow collector interface: cp-6/0/0 Interface state: Collecting flows Destination change successful
Other options for the request services flow-collector
change-destination interface cp-fpc/pic/port
command are immediately (which forces an instant switchover), gracefully (the default behavior that allows a gradual switchover), clear-files (which purges existing data files), and clear-logs (which
purges existing log files).
To verify that transfer log files are being scheduled
for delivery to the FTP servers, issue the request services flow-collector
test-file-transfer filename interface cp-fpc/pic/port
command. Include the desired export channel (zero
or one) and target FTP server (primary or secondary) with this command.
user@router1> request services flow-collector test-file-transfer test_file interface cp-6/0/0 channel-one primary Flow collector interface: cp-6/0/0 Interface state: Collecting flows Response: Test file transfer successfully scheduled
Another way you can check for the success of your file transfers is by analyzing the transfer log. A transfer log sends detailed information about files that are collected and processed by the flow collector interface. Table 1 explains the various fields available in the transfer log.
Field | Explanation |
---|---|
fn | Filename |
sz | File size |
nr | Number of records |
ts | Timestamp with the format of year (4 digits), month (2 digits), day (2 digits), hours (2 digits), minutes (2 digits), and seconds (2 digits). |
sf | Success flag—The values are 1 for success and 0 for failure. |
ul | Server URL |
rc | FTP result code |
er | FTP error text |
tt | Transfer time |
This is an example of a successful transfer log:
fn="cFlowd-py69Ni69-0-20040227_230438-at_4_0_0_4_3.bcp.bi.gz":sz=552569 :nr=20000:ts="20040227230855":sf=1:ul="ftp://10.63.152.1/tmp/server1/:"rc=250: er="":tt=3280
This is an example of a transfer log when an FTP session fails:
fn="cFlowd-py69Ni69-0-20040227_230515-at_4_0_0_2_8.bcp.bi.gz":sz=560436 :nr=20000:ts="20040227230855":sf=1:ul="ftp://10.63.152.1/tmp/server1/:"rc=250 :er="":tt=3290
As the flow collector interface receives and processes flow records, the PIC services logging process (fsad) handles the following tasks:
When the flow collector interface transfers a file to the FTP server, a temporary log file is created in the /var/log/flowc directory. The temporary log file has this filenaming convention:
<hostname>_<filename_prefix>_YYYYMMDD_hhmmss.tmp
hostname is the hostname of the transfer server, filename_prefix is the same value defined with the
filename-prefix
statement at the [edit services flow-collector transfer-log-archive] hierarchy level, YYYYMMDD is the year, month, and date, and hhmmss is the timestamp indicating hours, minutes, and seconds.After the log file has been stored in the router for the length of time specified by the
maximum-age
statement at the [edit services flow-collector transfer-log-archive] hierarchy level (the default is 120 minutes), the temporary log file is converted to an actual log file and the temporary file is deleted. The new log file retains the same naming conventions, except the extension is *.log.When the final log file is created and compressed, the PIC services logging process (fsad) tries to send the log file from the /var/log/flowc directory to an FTP server. You can specify up to five FTP servers to receive the log files by including the
archive-sites
statement at the [edit services flow-collector transfer-log-archive] hierarchy level. The logging process attempts to send the log file to one server at a time, in order of their appearance in the configuration. Upon the first successful transfer, the log file is deleted and the logging process stops sending log files to the remaining FTP servers in the list.If the log file transfer is not successful, the log file is moved to the /var/log/flowc/failed directory. Every 30 minutes, the logging process tries to resend the log files. After the log files are transferred successfully, they are deleted from the /var/log/flowc/failed directory.
Note:If the memory for a flow collector interface is full, the interface might drop incoming packets.
After the flow collector interface successfully delivers the processed information file to the FTP server, you can analyze the file. The file contains detailed information about the flows collected and processed by the flow collector interface. Table 2 explains the various fields available in the flow collector interface file.
Field | Explanation |
---|---|
linkDir | Link directory—A randomly generated number used to identify the record |
analyzer-address | Analyzer address |
analyzer-ID | Analyzer identifier |
ifAlias | Interface identifier |
source-address | Source address |
destination-address | Destination address |
packets | Number of packets |
bytes | Number of bytes |
start-time | Start time |
end-time | End time |
source-port | Source port |
destination-port | Destination port |
tcp_flag | TCP flag |
protocol | IP protocol number |
src_AS_number | Source AS number |
dst_AS_number | Destination AS number |
This is an example of output from a flow collector interface file:
11799241612374557782|10.10.10.1|server1|at_4_0_0_4|192.168.10.100|10.0.0.1|8| 3136|1077926402|1077926402|8224|12336|27|6|0|0