 |
Note: If you upgrade from the Monitoring Services PIC to the Adaptive Services PIC or MultiServices PIC for active flow monitoring, you must modify the interface name of your monitoring interface from mo-fpc/pic/port to sp-fpc/pic/port. |
In active flow monitoring, the routing platform participates in both the monitoring application and in the normal routing functionality of the network. Although the Monitoring Services PIC was designed initially for use as an offline passive flow monitoring tool, it can also be used in an active flow monitoring topology.
Table 36 shows which Juniper Networks PICs and corresponding routing platforms support active flow monitoring. For more information on Juniper Networks PICs, see the PIC guide that corresponds to your routing platform.
Table 36: Passive and Active Flow Monitoring PIC Support
Specified packets can be filtered and sent to the monitoring interface. For the Monitoring Services PIC, the interface name contains the mo- prefix. For the Adaptive Services PICs and MultiServices PICs, the interface name contains the sp- prefix.
|
Note: If you upgrade from the Monitoring Services PIC to the Adaptive Services PIC or MultiServices PIC for active flow monitoring, you must modify the interface name of your monitoring interface from mo-fpc/pic/port to sp-fpc/pic/port. |
The major active flow monitoring actions you can configure at the [edit forwarding-options] hierarchy level are as follows:
Unlike passive flow monitoring, you do not need to configure a monitoring group. Instead, you can send filtered packets to a monitoring services or adaptive services interface (mo- or sp-) by using sampling or discard accounting. Optionally, you can configure port mirroring or multiple port mirroring to direct packets to additional interfaces.
These active flow monitoring options provide a wide variety of actions that can be performed on network traffic flows. However, the following restrictions apply:
Because the Monitoring Services PIC, Adaptive Services PIC, and MultiServices PIC allow only one action to be performed at any one time, the following configuration options are available:
To configure active flow monitoring, complete these steps:
The first step in active flow monitoring is to configure the match conditions for acceptable traffic or quarantined traffic. Common match actions for active flow monitoring include sample, discard accounting, port-mirror, and accept. To configure, include the desired action statements and a counter as part of the then statement in a firewall filter and apply the filter to an interface.
In sampling, the routing platform reviews a portion of the traffic and sends reports about this sample to the flow monitoring server. Discard accounting traffic is counted and monitored, but not forwarded out of the routing platform. Port-mirrored traffic is copied and sent to another interface. Accepted traffic is forwarded to the intended destination.
Most of these match combinations are valid. However, you can either port-mirror or sample with the same traffic at the same time, but not perform more than one action simultaneously on the same packets.
- [edit]
- firewall {
-
- family inet {
-
- filter active_filter {
-
- term quarantined_traffic {
-
- from {
-
- source-address {
- 10.36.1.2/32;
- }
- }
-
- then {
- count quarantined-counter;
- sample;
- discard accounting;
- }
- }
-
- term copy_and_forward_the_rest {
-
- then {
- port-mirror;
- accept;
- }
- }
- }
- }
- }
Configure the input interfaces and apply the firewall filter that you defined earlier. Unlike passive flow monitoring, the input interfaces for active flow monitoring are not restricted, so you can select most standard network interfaces (such as ATM1 or Ethernet-based interfaces) as the input.
If you configure active flow monitoring with sampling, you can configure an interface filter in place of a firewall filter with the sampling statement at the [edit interfaces interface-name-fpc/pic/port unit unit-number family inet] hierarchy level.
- [edit]
- interfaces {
-
- so-2/2/0 {
-
- unit 0 {
-
- family inet {
-
- filter {
- input active_filter;
- }
-
- address 10.36.11.2/32 {
- destination 10.36.11.1;
- }
-
- sampling {
- (input | output | [input output]);
- }
- }
- }
- }
- }
You configure the monitoring services, adaptive services, or multiservices interfaces with the family inet statement so they can process IPv4 traffic. However, you must remember that a monitoring services interface uses an mo- prefix and adaptive services and multiservices interfaces use an sp- prefix.
- [edit]
- interfaces {
-
- sp-2/0/0 {
-
- unit 0 {
-
- family inet {
-
- address 10.36.100.1/32 {
- destination 10.36.100.2;
- }
- }
- }
- }
- }
Active flow monitoring records leave the routing platform through an export interface to reach the flow monitoring server.
Traffic flows can be exported in flow monitoring version 5, 8, and 9 formats for active flow monitoring. The default export format for flow monitoring records is version 5. To change the export format to flow monitoring version 8, include the version 8 statement at either the [edit forwarding-options accounting name output flow-server flow-server-address] or the [edit forwarding-options sampling output flow-server flow-server-address] hierarchy level. To change the export format to flow monitoring version 9, include the version9 template template-name statement at the [edit forwarding-options sampling output flow-server flow-server-address ] hierarchy level. For more information on flow record formats, see Flow Monitoring Output Formats.
To capture flow data generated by the Monitoring Services PIC, Adaptive Services PIC, or MultiServices PIC and export it to a flow server, you can use one of the following active flow monitoring methods:
If your needs for active flow monitoring are simple, you can collect flow records with a sampling group. Sampling does not require you to configure a monitoring group (as required in passive flow monitoring) because you can configure flow server information in the sampling hierarchy. When you wish to sample traffic, include the sampling statement at the [edit forwarding-options] hierarchy level.
The typical sampling configuration has one input interface and one export interface. The input interface is activated by the then sample statement in a firewall filter term. This match condition directs traffic to the sampling process. Alternatively, you can use an interface-based filter in place of a firewall filter if you include the sampling statement at the [edit interfaces interface-name-fpc/pic/port unit unit-number family inet] hierarchy level.
There are two types of sampling available: PIC-based sampling and Routing Engine-based sampling. PIC-based sampling occurs when a monitoring services or adaptive services interface is the target for the output of the sampling process. To enable PIC-based sampling, include the interface statement at the [edit forwarding-options sampling output] hierarchy level and specify a monitoring services or adaptive services interface as the output interface. If an output interface is not specified in the sampling configuration, sampling is performed by the Routing Engine.
To specify a flow server in a sampling configuration, include the flow-server statement at the [edit forwarding-options sampling output] hierarchy level. You must specify the IP address, port number, and flow monitoring version of the destination flow server. Routing Engine-based sampling supports flow aggregation of up to eight flow servers (version 5 servers and version 8 only) at a time. The export packets are replicated to all flow servers configured to receive them. In contrast, PIC-based sampling allows you to specify just one version 5 flow server and one version 8 server simultaneously. Flow servers operating simultaneously must have different IP addresses.
As part of the output interface statements, you must configure a source address. In contrast, the interface-level statements of engine-id and engine-type are both added automatically. However, you can override these values with manually configured statements to track different flows with a single flow collector, as needed. When you configure sampling, SNMP input and output interface index information is captured in flow records by default.
- [edit]
- forwarding-options {
-
- sampling {
-
- input {
-
- family inet {
- rate 1;
- }
- }
-
- output {
-
- flow-server 10.60.2.1 {
- port 2055;
- version 5;
- }
- flow-inactive-timeout 15;
- flow-active-timeout 60;
-
- interface sp-2/0/0 {
- engine-id 5;
- engine-type 55;
- source-address 10.60.2.2;
- }
- }
- }
- }
To perform discard accounting on specified traffic, you can collect flow records with the accounting statement at the [edit forwarding-options] hierarchy level. Like sampling, your topology must be simple (for example, one input interface and one export interface).
Again, you can collect flow records by specifying input and output interfaces. You can configure the input interface to perform discard accounting by applying a firewall filter that contains the then discard accounting statement. This match condition directs the filtered traffic to be converted into flow records and exported for analysis by the monitoring services or adaptive services interface. The original packets are then sent to the discard process. For the output, remember to specify the IP address and port of your flow server and the services interface you plan to use for processing flow records.
You must configure a source address, but the engine-id and engine-type output interface statements are added automatically. You can override these values manually to track different flows with a single flow collector. SNMP input and output interface index information is captured in flow records by default when you configure discard accounting.
- [edit]
- forwarding-options {
-
- accounting counter1 {
-
- output {
- flow-inactive-timeout 65;
- flow-active-timeout 65;
-
- flow-server 10.60.2.1 {
- port 2055;
- version 8;
-
- aggregation {
- protocol-port;
- source-destination-prefix;
- }
- }
-
- interface sp-2/0/0 {
- engine-id 1;
- engine-type 11;
- source-address 10.60.2.2;
- }
- }
- }
- }
Routing Engine-based sampling supports up to eight flow servers for both flow monitoring version 5 and version 8 configurations. The total number of flow servers is limited to eight, regardless of how many are configured for version 5 or version 8.
When you configure version 5 or version 8 sampling, the export packets are replicated to all flow servers configured to receive them. If two flow servers are configured to receive version 5 records, both flow servers will receive records for a specified flow.
|
Note: With Routing-Engine-based sampling, if multiple flow servers are configured with version 8 export format, all of them must use the same aggregation type (for example, all flow servers receiving version 8 export could be configured for source-destination aggregation type). |
The following configuration example allows replication of export packets to two flow servers.
- [edit]
- forwarding-options {
-
- sampling {
-
- input {
-
- family inet {
- rate 1;
- }
- }
-
- output {
-
- flow-server 10.10.3.2 {
- port 2055;
- version 5;
- source-address 192.168.164.119;
- }
-
- flow-server 172.17.20.62 {
- port 2055;
- version 5;
- source-address 192.168.164.119;
- }
- }
- }
- }
Flow monitoring version 9, which is based upon RFC 3954, provides a way to organize flow data into templates. Version 9 also provides a way to actively monitor MPLS traffic in addition to IPv4 traffic. Version 9 is not supported on the MultiServices 500 PIC or the AS-I PIC.
To activate templates in flow monitoring, you must configure a template and include that template in the version 9 flow monitoring configuration. Version 9 does not work in conjunction with versions 5 and 8.
To configure a version 9 template, include the template template-name statement at the [edit services flow-monitoring version9] hierarchy level. The JUNOS software supports three different templates: ipv4-template, mpls-template, and mpls-ipv4-template. To view the fields selected in each of these templates, see Version 9 Formats and Fields.
- [edit]
- services flow-monitoring {
-
- version9 {
# Specifies flow monitoring version 9.
-
- template mpls { # Specifies template you are configuring.
- template-refresh-rate {
packets 6000; # The default is 4800 packets and the range is 1–480000
# packets.
-
- seconds 90; # The default is 60 seconds and the range is 1–600 seconds.
option--refresh-rate {
- packets 3000; # The default is 4800 packets and the range is 1–480000
# packets.
- seconds 30; # The default is 60 seconds and the range is 1–600.
- flow-active-timeout 60; # The default is 60 seconds and the range is
#
10–600.
- flow-inactive-timeout
30; # The default is 60 seconds and the range 10–600.
- template-refresh-rate
seconds 10; # The default is 60 seconds and the
# range is 10–600
- option-refresh-rate seconds
10; # The default is 60 seconds and the range
# is 10–600 seconds.
-
- mpls-template {
- label-positions [1 | 2 | 3]; # Specifies label position for the MPLS template.
- }
- }
- }
- }
- }
You can export to only one template at a time to a maximum of eight flow servers for AS PICs and one flow server for all other PICs. To assign a template to a flow output, include the template template-name statement at the [edit forwarding options sampling output flow-server version9] hierarchy level:
- [edit]
- forwarding-options {
-
- sampling {
-
- input {
-
- family mpls {
- rate 1;
- run-length 1;
- }
- }
-
- output {
-
- flow-server 10.60.2.1 { # The IP address and port of the
flow server.
- port 2055;
- source-address 3.3.3.1;
-
- version9 { # Records are sent
to the flow server using version 9 format.
-
- template { # Indicates a template
will organize records.
- mpls; # Records are sent to
the MPLS template.
- }
- }
- }
- }
- }
- }
Routing Engine-based sampling supports up to eight flow servers for both version 5 and version 8 configurations. The total number of collectors is limited to eight, regardless of how many are configured for version 5 or version 8. When you configure sampling, the export packets are replicated to all collectors configured to receive them. If two collectors are configured to receive version 5 records, both collectors will receive records for a specified flow.
The following configuration example allows replication of export packets to two collectors.
- forwarding-options {
-
- sampling {
-
- input {
-
- family inet {
- rate 1;
- }
- }
-
- output {
-
- cflowd 10.10.3.2 {
- port 2055;
- version 5;
- source-address 192.168.164.119;
- }
-
- cflowd 172.17.20.62 {
- port 2055;
- version 5;
- source-address 192.168.164.119;
- }
- }
- }
- }
With this feature, you can configure up to eight flow servers to receive packets for a version 9 flow monitoring template. Once a flow server is configured to receive this data, it will also receive the following periodic version 9 flow monitoring updates:
With RE-based sampling, if multiple collectors are configured with version 8 export format, all of them must use the same aggregation-type
The option and template definition refresh period is configured on a per-template basis at the [edit services flow-monitoring] hierarchy level.
The following configuration example allows replication of version 9 export packets to two flow servers.
- forwarding-options {
-
- sampling {
-
- input {
-
- family inet {
- rate 1;
- }
- }
-
- output {
-
- flow-server 10.10.3.2 {
- port 2055;
-
- version9 {
-
- template {
- ipv4;
- }
- }
- }
-
- flow-server 172.17.20.62 {
- port 2055;
-
- version9 {
-
- template {
- ipv4;
- }
- }
- }
- flow-inactive-timeout 30;
- flow-active-timeout 60;
-
- interface sp-4/0/0 {
- source-address 10.10.3.4;
- }
- }
- }
- }
When you use flow monitoring version 8 records for active flow monitoring, you can configure an aggregate export timer. To configure this timer, include the aggregate-export-interval statement at the [edit forwarding-options sampling output] hierarchy level. The timer value has a default minimum setting of 90 seconds and a maximum value of 1800 seconds.
You can copy packets and reroute them to another interface by using port mirroring. To send packet copies to an interface, include the interface statement at the [edit forwarding-options port-mirroring family family-name output] hierarchy level and specify the interface to receive the traffic.
You can even send port-mirrored traffic to a monitoring services or adaptive services interface. If you choose this option, accepted traffic is copied and the packet copies are sent to the services interface for flow processing.
To configure how often packets are copied from the monitored traffic, include the rate statement at the [edit forwarding-options port-mirroring family family-name input] hierarchy level. A rate of 1 port-mirrors every packet, while a rate of 10 port-mirrors every tenth packet.
- [edit]
- forwarding-options {
-
- port-mirroring {
-
- family (inet | inet6) {
-
- input {
- rate 1;
- }
-
- output {
- interface sp-2/0/0.0;
- }
- }
- }
- }
For active flow monitoring, you can load-balance traffic across multiple Monitoring Services PICs using the same method as passive flow monitoring. The only difference is that you do not configure the input interface with the passive-monitor-mode statement at the [edit interfaces interface-name] hierarchy level.
To load-balance traffic for active flow monitoring, port-mirror the incoming packets to a tunnel services interface. Redirect this copy of the traffic to a filter-based forwarding instance by applying a firewall filter to the tunnel services interface. Configure the instance to send the traffic to a group of monitoring services interfaces. Finally, use a monitoring group to send flow records from the monitoring services interfaces to a flow server.
|
Note: When you load-balance port-mirrored traffic across several Monitoring Services interfaces, there are some limitations:
|
For detailed information on this method, see Copying and Redirecting Traffic with Port Mirroring and Filter-Based Forwarding.
To send port-mirrored traffic to multiple flow servers or packet analyzers, you can use the next-hop-group statement. The routing platform can make up to 16 copies of traffic per group and send the traffic to the next-hop group members you configure. A maximum of 30 groups can be configured on a routing platform at any given time. The port-mirrored traffic can be sent to any interface, except aggregated SONET/SDH, aggregated Ethernet, loopback (lo0), or administrative (fxp0) interfaces. To configure multiple port mirroring with next-hop groups, include the next-hop-group statement at the [edit forwarding-options] hierarchy level.
You must port-mirror the initial traffic to a tunnel interface so that it can be filtered and duplicated. Also, you need configure only the interface names for point-to-point interfaces, but you must configure the interface names and a next hop for multipoint interfaces (such as Ethernet).
- [edit]
- forwarding-options {
-
- port-mirroring {
-
- family inet {
-
- input {
- rate 1;
- }
-
- output {
- interface vt-3/3/0.1;
- no-filter-check;
- }
- }
- }
-
- next-hop-group ftp-traffic {
- interface so-4/3/0.0;
- interface so-0/3/0.0;
- }
-
- next-hop-group http-traffic {
-
- interface ge-1/1/0.0 {
- next-hop 10.12.1.2;
- }
-
- interface ge-1/2/0.0 {
- next-hop 10.13.1.2;
- }
- }
-
- next-hop-group default-collect {
- interface so-7/0/0.0;
- interface so-7/0/1.0;
- }
- }
|
Note: Next-hop groups are supported on M-series routers only, except the M120 router and the M320 router. |
Dynamic flow capture enables you to capture passively monitored packet flows on the basis of dynamic filtering criteria, using Dynamic Tasking Control Protocol (DTCP) requests. The flow-tap application extends the use of DTCP to intercept IPv4 packets in an active flow monitoring station and send a copy of packets that match filter criteria to one or more content destinations. Flow-tap data can be used for lawful intercept purposes and provides flexible trend analysis for detection of new security threats. The flow-tap application is supported on M-series and T-series routing platforms, except M160 routers and TX Matrix platforms.
|
Note: For information about dynamic flow capture, see Using a Dynamic Flow Capture Interface to Monitor Traffic On Demand. For information about DTCP, see Internet draft draft-cavuto-dtcp-01.txt at http://www.ietf.org/internet-drafts. |
For detailed information about the flow-tap application, see the following sections:
The flow-tap architecture consists of one or more mediation devices that send requests to a Juniper Networks routing platform to monitor incoming data. Any packets that match specific filter criteria are forwarded to a set of one or more content destinations:
Following is a sample filter configuration; note that it is dynamically generated by the router (no user configuration is required):
Figure 45 shows a sample topology that uses two mediation devices and two content destinations.
Figure 45: Flow-Tap Topology Diagram
To configure an AS PIC interface for the flow-tap service, include the interface statement at the [edit services flow-tap] hierarchy level:
You can assign any AS PIC in the active monitoring station for flow-tap service, and use any logical unit on the PIC.
|
Note: You cannot configure dynamic flow capture and flow-tap features on the same router simultaneously. |
You must also configure the logical interface at the [edit interfaces] hierarchy level:
You can add an extra level of security to DTCP transactions between the mediation device and the router by enabling DTCP sessions on top of the SSH layer. To configure, include the flow-tap-dtcp statement at the [edit system services] hierarchy level:
To configure client permissions for viewing and modifying flow-tap configurations and for receiving tapped traffic, include the permissions statement at the [edit system login class class-name] hierarchy level:
The permissions needed to use flow-tap features are as follows:
You can also specify user permissions on a RADIUS server, for example:
For details on [edit system] and RADIUS configuration, see the JUNOS System Basics Configuration Guide.
The following restrictions apply to flow-tap services:
The following example shows all the parts of a complete flow-tap configuration.
- services {
-
- flow-tap {
- interface sp-1/2/0.100;
- }
- }
- interfaces {
-
- sp-1/2/0 {
-
- unit 100 {
- family inet;
- }
- }
- }
- system {
-
- services {
-
- flow-tap-dtcp {
-
- ssh {
- connection-limit 5;
- rate-limit 5;
- }
- }
- }
-
- login {
-
- class ft-class {
- permissions flow-tap-operation;
- }
-
- user ft-user1 {
- class ft-class;
-
- authentication {
- encrypted-password “xxxx”;
- }
- }
- }
- }
