[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

Configuring Passive Flow Monitoring

Table 27 shows which Juniper Networks PICs and routing platforms support passive flow monitoring. The PICs receive passively monitored network traffic from an input interface (SONET/SDH, ATM2 IQ, Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet), convert the received packets into flow records, and export them to a flow server for further analysis.

Table 27: Passive Flow Monitoring PIC Support

PIC Type

M40e

M160

T-series/
M320

Monitoring Services PIC

Yes

Yes

No

Monitoring Services II PIC

Yes

Yes

Yes

Monitoring Services III PIC

Yes

Yes

Yes

MultiServices 400 PIC (Type 2)

Yes

No

Yes

The key configuration hierarchy statement for passive flow monitoring is the monitoring statement found at the [edit forwarding-options] hierarchy level. At minimum, you must configure a VRF routing instance to direct the traffic to a monitoring services interface for flow processing.

However, there are several options you can use that add complexity to passive flow monitoring. For example, you can configure the routing platform to direct traffic into a routing instance and deliver the traffic into a monitoring group. You can also use port mirroring and filter-based forwarding to copy and redirect traffic. Optionally, you can configure the monitoring station to encrypt flow output before it is sent to a flow server for processing, to send flow records to a flow collector, or to process on-demand monitoring requests with dynamic flow capture.

The following sections explain the variety of passive flow monitoring topics:

Monitoring Traffic with a VRF Instance and a Monitoring Group

The first way you can implement passive flow monitoring is to direct traffic into a VRF routing instance and use a monitoring group to export this traffic to a flow server for analysis. Complete the following tasks:

Specifying a Firewall Filter to Select Traffic to Monitor

When you define a firewall filter, you select the initial traffic to be monitored. To configure a firewall filter, include the filter statement at the [edit firewall family inet] hierarchy level. All filtered traffic to be monitored must be accepted.

[edit]
firewall {
family inet {
filter input-monitoring-filter {
term 1 {
from {
destination-address {
10.7.0.0/16;
}
}
then {
count counter1;
accept;
}
}
term 2 {
from {
destination-address {
10.6.0.0/16;
}
}
then {
count counter2;
accept;
}
}
}
}
}

Configuring Input Interfaces, Monitoring Services Interfaces, and Export Interfaces

After creating the input filter, you need to configure the interfaces where traffic will enter the routing platform. To enable passive flow monitoring for SONET/SDH input interfaces, include the passive-monitor-mode statement at the [edit interfaces so-fpc/pic/port unit unit-number] hierarchy level. This mode disables the routing platform from participating in the network as an active device. On SONET/SDH interfaces, passive monitor mode suppresses SONET keepalives.

For ATM2 IQ interfaces, passive monitor mode suppresses the sending and receiving of ATM Operations, Administration, and Maintenance (OAM) and Integrated Local Management Interface (ILMI) control messages. To enable passive flow monitoring for ATM2 IQ input interfaces, include the passive-monitor-mode statement at the [edit interfaces at-fpc/pic/port] hierarchy level. ATM passive monitoring supports the following interface encapsulation types: Cisco-compatible ATM Network Layer Protocol ID (NLPID) (atm-cisco-nlpid), ATM NLPID (atm-nlpid), ATM Point-to-Point Protocol (PPP) over ATM Adaptation Layer 5 (AAL5)/ logical link control (LLC) (atm-ppp-llc), ATM PPP over raw AAL5 (atm-ppp-vc-mux), ATM LLC/ subnetwork attachment point (SNAP) (atm-snap), and ATM virtual circuit (VC) multiplexing (atm-vc-mux).

Ethernet-based interfaces support both per-port passive monitoring and per-VLAN passive monitoring. For Fast Ethernet interfaces, include the passive-monitor-mode statement at the [edit interfaces fe-fpc/pic/port] hierarchy level. For Gigabit Ethernet interfaces, include the passive-monitor-mode statement at the [edit interfaces ge-fpc/pic/port] hierarchy level. On Ethernet-based interfaces, passive monitor mode disables the Routing Engine from receiving packets and prevents the routing table from transmitting packets. You can verify this by the presence of the No-receive and No-transmit interface flags in the output of the show interfaces (fe | ge)-fpc/pic/port command.

Note: The following restrictions apply to passive flow monitoring on Ethernet-based interfaces:

  • No special encapsulation types are allowed, so you must configure Ethernet encapsulations only.
  • When you configure the passive-monitor-mode statement, destination MAC address filters applied to incoming interfaces are disabled by default.
  • The flow-control statement at the [edit interfaces ge-fpc/pic/port gigether-options] or [edit interfaces fe-fpc/pic/port fastether-options] hierarchy level does not work when passive flow monitoring is enabled.

In addition to passive monitor mode, apply the previously defined firewall filter to the interface with the filter statement at the [edit interfaces interface-name-fpc/pic/port unit unit-number family inet] hierarchy level:

[edit]
interfaces {
so-0/0/0 {
description “SONET/SDH input interface”;
encapsulation ppp;
unit 0 {
passive-monitor-mode;
family inet {
filter {
input input-monitoring-filter;
}
}
}
}
at-1/0/0 {
description “ATM2 IQ input interface”;
passive-monitor-mode;
atm-options {
pic-type atm2;
vpi 0 {
maximum-vcs 255;
}
}
unit 0 {
encapsulation atm-snap;
vci 0.100;
family inet {
filter {
input input-monitoring-filter;
}
}
}
}
ge-2/0/0 {
description “Gigabit Ethernet input interface”;
passive-monitor-mode;
unit 0 {
family inet {
filter {
input input-monitoring-filter;
}
}
}
}
}

Configure the interfaces on the Monitoring Services PIC or Monitoring Services II PIC with the family inet statement at the [edit interfaces mo-fpc/pic/port unit unit-number] hierarchy level. The statement allows the interfaces to process IPv4 traffic received from the input interfaces.

When you use VRF instances, you need to configure two logical interfaces. The first (unit 0) is part of the inet.0 routing table and sources the flow packets. The second (unit 1) is configured as part of the VRF instance so the monitoring services interface can serve as a valid next hop for packets received in the instance.

You can also capture options packets and time-to-live (TTL) exceeded information when the monitoring services interface processes flow records. To configure, include the receive-options-packets and receive-ttl-exceeded statements at the [edit interfaces mo-fpc/pic/port unit unit-number family inet] hierarchy level:

[edit]
interfaces {
mo-4/0/0 {
unit 0 {
family inet {
receive-options-packets;
receive-ttl-exceeded;
}
}
unit 1 {
family inet;
}
}
mo-4/1/0 {
unit 0 {
family inet;
}
unit 1 {
family inet;
}
}
mo-4/2/0 {
unit 0 {
family inet;
}
unit 1 {
family inet;
}
}
mo-4/3/0 {
unit 0 {
family inet;
}
unit 1 {
family inet;
}
}
}

You must also configure the export interface where flow packets exit the monitoring station and are sent to the flow server.

On output interfaces, you can apply a firewall filter that leads to a filter-based forwarding routing instance. This is useful if you want to port-mirror traffic to multiple Monitoring Services PICs or flow collection services interfaces. To configure, include the output statement at the [edit interfaces interface-name unit logical-unit-number family inet filter] hierarchy level. For more information, see Using Filter-Based Forwarding to Export Monitored Traffic to Multiple Destinations.

[edit]
interfaces
fe-3/0/0 {
description “export interface to flow server”;
unit 0 {
family inet;
address ip-address;
filter {
output output-filter-name;
}
}
}

Establishing a VRF Instance for the Monitored Traffic

After the firewall filter and interfaces are ready, create a VPN routing and forwarding (VRF) instance. The filtered traffic enters the VRF instance and is shared only between the input interfaces and the monitoring services output interfaces. In this case, a group of four monitoring services interfaces is used as the next hop.

[edit]
routing-instances {
monitoring-vrf {
instance-type vrf;
interface so-0/0/0.0;
interface so-0/1/0.0;
interface mo-4/0/0.1;
interface mo-4/1/0.1;
interface mo-4/2/0.1;
route-distinguisher 69:1;
vrf-import monitoring-vrf-import;
vrf-export monitoring-vrf-export;
routing-options {
static {
route 0.0.0.0/0 next-hop [mo-4/0/0.1 mo-4/1/0.1 mo-4/2/0.1];
}
}
}
}

Configuring a Monitoring Group to Send Traffic to the Flow Server

You collect flow records by specifying output interfaces in a monitoring group. In general, the monitoring services interfaces are the output interfaces. The logical unit number on the output interfaces when used in conjunction with a VRF instance must be 1. To configure, include the output statement at the [edit forwarding-options monitoring group-name family inet] hierarchy level.

Note: Because routing instances determine the input interface, the input statement at the [edit forwarding-options monitoring group-name family inet] hierarchy level has been removed in JUNOS Release 6.0 and later. If you have a configuration that contains this old statement, we recommend that you update your configuration and remove the statement.

As part of the mo-fpc/pic/port statement at the [edit forwarding-options monitoring group-name family inet output interface] hierarchy level, you must specify a source address for transmission of flow information. You can use the routing platform ID IP address, the IP address of the input interface, or any local IP address of your choice as the source address. If you provide a different source-address statement for each monitoring services output interface, you can track which interface processes a particular flow record.

All other statements at this level (engine-id, engine-type, input-interface-index, and output-interface-index) are dynamically generated, but can be configured manually. To reset outgoing interface or incoming interface indexes that were once configured manually, configure the input-interface-index or outgoing-interface-index statements with a value of 0 at the [edit forwarding-options monitoring group-name family inet output interface interface-name] hierarchy level.

To specify the flow server IP address and port number, include the flow-server ip-address port port-numberstatement at the [edit forwarding-options monitoring group-name family inet output] hierarchy level. You can specify up to eight flow servers in a monitoring group and the IP address for each server must be unique. flow records are exported and load-balanced between all active flow servers.

Once you configure the VRF and monitoring group statements, traffic enters the input interfaces, passes to the monitoring services interfaces for processing, and is discarded. The resulting flow description packets exit the monitoring station through the export interface. If you want traffic to travel to destinations other than the monitoring services interfaces, or need to establish additional analysis, see the section Copying and Redirecting Traffic with Port Mirroring and Filter-Based Forwarding.

Note: You must complete interface configuration on the Monitoring Services or Monitoring Services II PIC before an interface can be added into a monitoring group. For more information, see Configuring Input Interfaces, Monitoring Services Interfaces, and Export Interfaces.

[edit]
forwarding-options {
monitoring group1 {
family inet {
output {
export-format cflowd-version-5;
flow-active-timeout 60;
flow-inactive-timeout 30;
flow-server 192.168.245.1 port 2055;
flow-server 192.168.245.2 port 2055;
interface mo-4/0/0.1 {
engine-id 1;
engine-type 1;
input-interface-index 44;
output-interface-index 54;
source-address 192.168.245.1;
}
interface mo-4/1/0.1 {
engine-id 2;
engine-type 1;
input-interface-index 45;
output-interface-index 55;
source-address 192.168.245.1;
}
interface mo-4/2/0.1 {
engine-id 3;
engine-type 1;
input-interface-index 46;
output-interface-index 56;
source-address 192.168.245.1;
}
}
}
}
}

Configuring Policy Options

When you use a group of next hops in your monitoring group, you can load-balance traffic and distribute it to the export interfaces if you configure policy options. To configure, include the load-balance per-packet statement at the [edit policy-options policy-statement policy-name then] hierarchy level. You can also reject import and export of VRF routes by including the reject statement at the [edit policy-options policy-statement policy-name then] hierarchy level.

[edit]
routing-options {
forwarding-table {
export pplb;
}
}
policy-options {
policy-statement monitoring-vrf-import {
then {
reject;
}
}
policy-statement monitoring-vrf-export {
then {
reject;
}
}
policy-statement pplb {
then {
load-balance per-packet;
}
}
}

Option: Stripping MPLS Labels on ATM, Ethernet-Based, and SONET/SDH Interfaces

Because flow monitoring can be performed only on IPv4 packets, any packets containing MPLS labels must have the labels removed before monitoring can occur. To remove MPLS labels from packets as they enter an ATM2 IQ, Ethernet-based, or SONET/SDH interface, include the pop-all-labels statement at the [edit interfaces interface-name-fpc/pic/port (atm | fastether | gigether | sonet)-options mpls] hierarchy level. If you use static MPLS labels, we recommend you assign label values from 10000 through 99999 to avoid using the label ranges reserved by the JUNOS software.

To remove a specified number of labels from selected packets with MPLS labels, include the required-depth statement at the [edit interfaces interface-name-fpc/pic/port (atm | fastether | gigether | sonet)-options mpls pop-all-labels] hierarchy level. A required-depth value of 1 removes labels from all packets containing only one MPLS label, a value of 2 removes labels from all packets containing only two MPLS labels, and a value of [1 2] removes labels from all packets containing either one or two MPLS labels. The required-depth value of [1 2] is the default setting. When you configure the required-depth statement, you must configure the same value for all ports on the same PIC.

The labels are removed and discarded as soon as they arrive at the interface. As a result, no MPLS filters can be applied to the stripped labels, no statistics are generated for the labels, and you cannot apply an IP filter to the incoming packets. No Tunnel Services PIC is required to perform MPLS label stripping.

[edit]
interfaces {
at-/fpc/pic/port {
atm-options {
mpls {
pop-all-labels {
required-depth 1;
}
}
}
}
(fe | ge)-fpc/pic/port {
(fastether | gigether)-options {
mpls {
pop-all-labels {
required-depth [1 2];
}
}
}
}
so-fpc/pic/port {
sonet-options {
mpls {
pop-all-labels {
required-depth 2;
}
}
}
}
}

Copying and Redirecting Traffic with Port Mirroring and Filter-Based Forwarding

This section discusses additional techniques you can use with the passive flow monitoring application:

To implement the filter-based forwarding enhancement methods, see the following sections:

Specifying Port Mirroring Input and Output

This step works in conjunction with the action specified by the port-mirror statement configured at the [edit firewall family (inet | inet6) filter filter-name term term-name then] hierarchy level. At this point, you select input and output statements to determine where the copies of the IPv4 or IPv6 packets are sent. To configure, include the input and output statements at the [edit forwarding-options port-mirroring family family-name] hierarchy level. The traffic to be monitored is copied, port-mirrored, and sent to the packet analyzer for analysis. On M-series routers, you can port-mirror either IPv4 or IPv6 packets at one time. On M320 and T-series routing platforms, you can port-mirror both IPv4 and IPv6 packets simultaneously.

The port-mirrored copy of the traffic can travel only to a single next hop. As a result, only one type of analysis can be performed if the packets are sent to a packet analyzer through a physical next hop. If more than one type of analysis is desired, a tunnel interface must be used as the next hop for port mirroring. When the mirrored copy of the traffic arrives at the virtual tunnel interface, it can be filtered, split into groups, and redirected to multiple exit interfaces and packet analyzers.

For your input requirements, include the rate and run-length statements at the [edit forwarding-options port-mirroring family family-name input] hierarchy level. For your output requirements, specify the target interface with the interface statement at the [edit forwarding-options port-mirroring family family-name output] hierarchy level.

By default, a filter cannot be applied to an interface where port-mirrored traffic is received. To allow the tunnel services interface to be used as a filtered next hop, include the no-filter-check statement at the [edit forwarding-options port-mirroring family family-name output] hierarchy level.

[edit]
forwarding-options {
port-mirroring {
family (inet | inet6) {
input {
rate 1;
run-length 5;
}
output {
interface vt-0/2/0.0;
no-filter-check;
}
}
}
}

Note: Before JUNOS Release 7.4, you could configure the input and output statements at the [edit forwarding-options port-mirroring] hierarchy level. However, this older syntax has been revised to extend port-mirroring support to IPv6 packets. If you have a configuration that contains the older syntax, we recommend that you update your configuration to the new syntax listed above.

Creating a Firewall Filter to Split the Port-Mirrored Traffic into Different Instances

If you need to split the copy of the monitored traffic into separate groups and send these filtered packets to different analyzers, devise a firewall filter that selects some traffic for sampling and some traffic for discarding. In this case, UDP traffic is sent into one routing instance, TCP traffic is diverted into a second routing instance, and all other traffic is discarded. In a later step, you will define the filter-based forwarding routing instances specified in the then statements shown in this filter.

[edit]
firewall {
family inet {
filter tunnel-interface-filter {
term tcp {
from {
protocol tcp;
}
then {
count tcp;
routing-instance tcp-routing-table;
}
}
term udp {
from {
protocol udp;
}
then {
count udp;
routing-instance udp-routing-table;
}
}
term rest {
then {
count rest;
discard;
}
}
}
}
}

Applying the Firewall Filter to a Tunnel PIC Interface

Once the firewall filter is defined, apply it as an input filter on a tunnel interface. This is required if the firewall filter defines two or more types of traffic or export interfaces. However, if the firewall filter only specifies one type of traffic and one export interface, you can apply the filter directly to the export interface.

[edit]
interfaces {
vt-0/2/0 {
unit 0 {
family inet {
filter {
input tunnel-interface-filter;
}
}
}
}
}

Using Filter-Based Forwarding to Export Monitored Traffic to Multiple Destinations

The firewall filter called tunnel-interface-filter that you made earlier sends UDP traffic into one filter-based forwarding routing instance called udp-routing-table, sends TCP traffic into a second filter-based forwarding routing instance called tcp-routing-table, and discards all other packets. Here you will configure the filter-based forwarding instances.

Configure an export interface for each of your routing instances by including a static next hop. To configure, include the route statement at the [edit routing-instances instance-name routing-options static] hierarchy level and specify a next-hop address or interface.

[edit]
routing-instances {
tcp-routing-table {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop es-3/1/0.0;
}
}
}
udp-routing-table {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 10.9.1.2;
}
}
}
}

Configuring a Routing Table Group to Add Interface Routes into the Forwarding Instance

Next, import the interface routes into the forwarding instance. This step is necessary because the next hops specified in the forwarding instances must be installed in the forwarding instances themselves. To configure, include the import-rib statement at the [edit routing-options rib-groups group-name] hierarchy level. The export statement at the [edit routing-options forwarding-table] hierarchy level and the pplb policy enables load balancing.

[edit]
routing-options {
interface-routes {
rib-group inet bc-vrf;
}
rib-groups {
bc-vrf {
import-rib [inet.0 tcp-routing-table.inet.0 udp-routing-table.inet.0];
}
}
forwarding-table {
export pplb;
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}

Option: Using an ES PIC to Send Traffic to a Packet Analyzer

You can send some or all of the traffic securely to the packet analyzer using IPSec and an ES PIC. In this case, the TCP traffic is encrypted, sent over an IPSec tunnel, and received by the packet analyzer. For more information on configuring IPSec on the ES PIC, see IPSec or the JUNOS System Basics Configuration Guide.

[edit]
interfaces {
es-3/1/0 {
unit 0 {
tunnel {
source 10.8.8.1;
destination 10.8.8.2;
}
family inet {
ipsec-sa sa-esp;
address 3.3.3.1/32 {
destination 3.3.3.2;
}
}
}
}
fe-3/2/1 {
unit 0 {
family inet {
address 10.8.8.1/30;
}
}
}
}
security {
ipsec {
proposal esp-sha1-3des {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 180;
}
policy esp-group2 {
perfect-forward-secrecy {
keys group2;
}
proposals esp-sha1-3des;
}
security-association sa-esp {
mode tunnel;
dynamic {
ipsec-policy esp-group2;
}
}
}
ike {
proposal ike-esp {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
lifetime-seconds 180;
}
policy 10.8.8.2 {
mode aggressive;
proposals ike-esp;
pre-shared-key ascii-text "$9$qmQnuORrlMBIds2oiH0BIESe";
}
}
}

Option: Applying a Firewall Filter to an Output Interface

On output interfaces, you can apply a firewall filter that leads to a filter-based forwarding routing instance. This is useful if you want to port-mirror traffic to multiple Monitoring Services PICs or flow collection services interfaces. To configure, include the output statement at the [edit interfaces interface-name unit logical-unit-number family inet filter] hierarchy level.

[edit]
interfaces
fe-3/1/0 {
description “export interface to flow collection services interfaces”;
unit 0 {
family inet;
address ip-address;
filter {
output output-filter-name;
}
}
}

Using a Flow Collector Interface to Process and Export Multiple Flow Records

Basic passive monitoring can sometimes create a large number of flow records. However, you can manage multiple flow records with a flow collector interface. You can create a flow collector interface from a Monitoring Services II PIC. The flow collector interface combines multiple flow records received from a monitoring services interface into a compressed ASCII data file and exports the file to an FTP server.

To convert a Monitoring Services II PIC into a flow collector interface, include the flow-collector statement at the [edit chassis fpc fpc-slot pic pic-slot monitoring-services application] hierarchy level. To restore the monitoring functions of a Monitoring Services II PIC, include the monitor statement at the [edit chassis fpc fpc-slot pic pic-slot monitoring-services application] hierarchy level.

After you commit the configuration to convert the PIC between the monitor and flow-collector service types, you must take the PIC offline and then bring the PIC back online. Rebooting the routing platform does not enable the new service type. You can use the Monitoring Services II PIC for either flow collection or monitoring, but not both types of service simultaneously.

A flow collector interface, designated by the cp-fpc/pic/port interface name, requires three logical interfaces for correct operation. Units 0 and 1 are used respectively as export channels 0 and 1 to send the compressed ASCII data files to an FTP server. You must include a class-of-service (CoS) configuration for these two export channels to provide adequate bandwidth for file transmission. Unit 2 is used as a flow receive channel to receive flow records from a monitoring services interface.

Note: Unlike conventional interfaces, IP addresses for flow collector logical interfaces set up a point-to-point connection between the Routing Engine and the flow collector. The address statement at the [edit interfaces cp-fpc/pic/port unit unit-number family inet] hierarchy level corresponds to the IP address of the Routing Engine. Likewise, the destination statement at the [edit interfaces cp-fpc/pic/port unit unit-number family inet address ip-address] hierarchy level corresponds to the IP address of the flow collector interface. As a result, you must configure the destination statement for Units 0 and 1 (export channels 0 and 1) with local addresses that can reach the FTP server. Similarly, configure the destination statement for Unit 2 (flow receive channel) with a local IP address so it can reach the monitoring services interface that sends flow records.

To activate flow collector services after the Monitoring Services II PIC is converted into a flow collector, include the flow-collector statement at the [edit services] hierarchy level. You also need to configure several additional components:

To specify a flow collector interface as the destination for flow records coming from a Monitoring Services or Monitoring Services II PIC, include the collector-pic statement at the [edit forwarding-options monitoring group-name family inet output flow-export-destination] hierarchy level. You can select either the flow collector interface or a flow server as the destination for flow records, but you cannot select both destination types simultaneously.

There is also a Juniper Networks enterprise Management Information Base (MIB) for the flow collector interface. The Flow Collector Services MIB allows you to use SNMP to monitor the flow collector interface. The MIB provides statistics on files, records, memory, FTP, and error states of a flow collector interface. It also provides SNMP traps for unavailable destinations, unsuccessful file transfers, flow overloading, and memory overloading. For more information, see the JUNOS Network Management Configuration Guide or view the enterprise-specific Juniper Networks MIBs at http://www.juniper.net/techpubs/software/junos/mibs.html.

In summary, to implement the flow collector service, include statements at the [edit chassis], [edit interfaces], [edit forwarding-options], and [edit services] hierarchy levels. The excerpt on the following pages shows the flow collector service configuration hierarchy. For a full configuration example, see Example: Flow Collector Interface Configuration.

[edit]
chassis {
fpc fpc-slot {
pic pic-slot {
monitoring-services {
application flow-collector;
}
}
}
}
interfaces {
cp-fpc/pic/port {
description ”flow_collector_interface”;
unit 0 {
family inet {
address ip-address {
destination ip-address;
}
}
}
unit 1 {
family inet {
address ip-address {
destination ip-address;
}
}
}
unit 2 {
family inet {
address ip-address {
destination ip-address;
}
}
}
}
interface-fpc/pic/port {
description “export_interface”;
unit 0 {
family inet {
address ip-address;
}
}
}
mo-fpc/pic/port {
description “monitoring_services_interface”;
unit 0 {
family inet;
}
}
SONET/SDH, ATM2 IQ, or Ethernet-based-interface-fpc/pic/port {
description “ input_interface”;
encapsulation encapsulation-type;
passive-monitor-mode; # Apply to the logical interface for SONET/SDH
}
}
forwarding-options {
monitoring group1 {
family inet {
output {
export-format cflowd-version-5;
flow-active-timeout value;
flow-inactive-timeout value;
flow-export-destination collector-pic;
interface mo-fpc/pic/port {
source-address ip-address;
}
}
}
}
}
services {
flow-collector {
analyzer-address ip-address;
analyzer-id name;
retry value;
retry-delay seconds;
destinations {
"ftp://username@ftp-server-address-1//directory/" {
password "encrypted-password";
}
"ftp://username@ftp-server-address-2//directory/" {
password "encrypted-password";
}
}
file-specification {
file-specification-name {
}
data-format flow-compressed;
transfer timeout value record-level size;
}
}
interface-map {
file-specification file-specification-name;
collector cp-fpc/pic/port;
interface-name {
file-specification file-specification-name;
collector cp-fpc/pic/port;
}
}
transfer-log-archive {
filename-prefix filename;
maximum-age timeout-value;
archive-sites {
"ftp://username@ip-address//directory/" {
password "encrypted-password";
}
}
}
}

Using a Dynamic Flow Capture Interface to Monitor Traffic On Demand

Dynamic flow capture enables you to capture packet flows based on filtering criteria that you specify in real time. Unlike traditional flow monitoring that requires filtering criteria to be established before operation, dynamic flow capture uses an on demand control protocol that allows you to modify the filtering criteria as network conditions change.

The dynamic flow capture architecture consists of one or more control sources that send Dynamic Tasking Control Protocol (DTCP) requests to a monitoring station. The requests contain filtering criteria that specify which incoming traffic should be monitored, and the monitoring station forwards any packets that match the filter criteria to a set of one or more content destinations.

Note: The DFC PIC forwards the entire packet content to the content destination, rather than just a content record.

Figure 42 shows a sample topology that contains control sources, a monitoring station, and content destinations.

Figure 42: Dynamic Flow Capture Topology

Image g017075.gif

To configure dynamic flow capture, perform the following tasks:

Configuring the Capture Group

A dynamic flow capture capture group defines a profile of dynamic flow capture configuration information. The static configuration includes information about control sources, content destinations, and notification destinations. Dynamic configuration is added through interaction with control sources using a control protocol.

To configure a capture group, include the capture-group statement at the [edit services dynamic-flow-capture] hierarchy level:

[edit services dynamic-flow-capture]
capture-group client-name {
content-destination identifier {
address address;
ttl hops;
}
control-source identifier {
allowed-destinations [ destination ];
no-syslog;
notification-targets [ address address port port-number ];
service-port port-number;
shared-key value;
source-addresses [ address ];
}
input-packet-rate-threshold rate;
interfaces interface-name;
pic-memory-threshold percentage percentage;
}

To specify the capture-group, assign it a unique client-name that associates the information with the requesting control sources.

Configuring the Content Destination

You must specify a destination for the packets that match dynamic flow capture filter criteria. To configure, include the content-destination statement at the [edit services dynamic-flow-capture capture-group client-name] hierarchy level:

[edit services dynamic-flow-capture capture-group client-name]
content-destination identifier {
address address;
ttl hops;
}

Assign the content-destination a unique identifier. In addition, you must specify its IP address, and you can optionally set a time-to-live (TTL) value for the IP-IP header:

Configuring the Control Source

You configure information about the control source, including allowed source addresses and destinations and authentication key values. To configure the control source information, include the control-source statement at the [edit services dynamic-flow-capture] hierarchy level:

[edit services dynamic-flow-capture capture-group client-name]
control-source identifier {
allowed-destinations [ destination-identifier ];
no-syslog;
notification-targets [ address address port port-number ];
service-port port-number;
shared-key value;
source-addresses [ address ];
}

Assign the control-source statement with a unique identifier. You can also include values for the following statements:

Configuring the Dynamic Flow Capture Interface

You specify the interface that interacts with the control sources configured in the same dynamic flow capture group. A Monitoring Services III PIC can belong to only one capture group, and you can configure only one PIC for each group.

To configure a dynamic flow capture interface, include the interfaces statement at the [edit services dynamic-flow-capture] hierarchy level:

[edit services dynamic-flow-capture capture-group client-name]
interfaces interface-name;

You specify dynamic flow capture interfaces using the dfc- identifier at the [edit interfaces] hierarchy level. Three logical units are required on each dynamic flow capture interface, numbered 0, 1, and 2. You cannot configure any other logical interfaces.

The following example shows the configuration necessary to set up a dynamic flow capture interface:

[edit interfaces dfc-0/0/0]
unit 0 {
family inet {
address 10.1.0.0/32 { # Address of the Routing Engine for the DFC PIC.
destination 10.36.100.1; # Address of DFC PIC; used by the
# control source to correspond with the monitoring station.
}
}
}
unit 1 { # Receives data packets on this logical interface.
family inet;
}
unit 2 { # Sends copies of matched packets from this logical interface.
family inet;
}

In addition, you must configure the dynamic flow capture application to run on the DFC PIC in the correct chassis location. The following example shows this configuration at the [edit chassis] hierarchy level:

[edit chassis]
fpc 0 {
pic 0 {
monitoring-services application dynamic-flow-capture;
}
}

For more information on configuring chassis properties, see the JUNOS System Basics Configuration Guide.

Option: Configuring Thresholds

You can optionally specify threshold values for situations in which warning messages will be recorded in the system log:

To configure, include the input-packet-rate-threshold or pic memory-threshold statements at the [edit services dynamic-flow-capture capture-group client-name] hierarchy level:

[edit services dynamic-flow-capture capture-group client-name]
input-packet-rate-threshold rate;
pic-memory-threshold percentage percentage;

If these statements are not configured, no threshold messages are logged. The threshold settings are configured for the capture group as a whole.

Option: Configuring System Logging

By default, control protocol activity is logged as a separate system log facility, dfc. To modify the filename or level at which control protocol activity is recorded, include the following statements at the [edit syslog] hierarchy level:

[edit syslog]
file dfc.log {
dfc any;
}

To cancel logging, include the no-syslog statement at the [edit services dynamic-flow-capture capture-group client-name control-source identifier] hierarchy level:

[edit services dynamic-flow-capture capture-group client-name control-source identifier]
no-syslog;

Option: Monitoring Dynamic Flow Capture by Using SNMP

In JUNOS Release 7.5 and later, the Dynamic Flow Capture MIB provides a way to monitor dynamic flow capture information by using Simple Network Management Protocol (SNMP). The MIB provides the same information that you can view with the show services dynamic-flow-capture content-destination, show services dynamic-flow-capture control-source, and show services dynamic-flow-capture statistics commands. For more information, see the JUNOS Network Management Configuration Guide.

Hardware and Software Considerations

There are several hardware and software considerations when you implement passive flow monitoring. When defining the hardware requirements of the monitoring station, keep in mind the following:

When defining a traffic monitoring strategy, keep in mind the following:

You can also configure the monitoring station to collect periodic flow reports for flows that last longer than the configured active timeout. To set this activity timer, include the flow-active-timeout statement at the [edit forwarding-options monitoring group-name family inet output] hierarchy level. The timer value can be from 60 seconds through 1800 seconds, with a default value of 180 seconds.

[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]