Configuring Inline Active Flow Monitoring on PTX Series Routers
SUMMARY This topic describes how to configure inline active flow monitoring on PTX Series routers for IPv4 and IPv6 traffic.
Platform and Feature Support
Table 1 lists the PTX Series platform support for various types of traffic for inline active flow monitoring.
|
Platform |
Support |
|---|---|
|
PTX3000 Series |
Junos OS 18.1R1—IPv4 and IPv6 traffic (both IPFIX and version 9) Junos OS 18.2R1—MPLS, MPLS-IPv4, and MPLS-IPv6 traffic. |
|
PTX5000 Series |
Junos OS 18.1R1—IPv4 and IPv6 traffic (both IPFIX and version 9) Junos OS 18.2R1, MPLS, MPLS-IPv4, and MPLS-IPv6 traffic. |
|
PTX1000 |
Junos OS 17.3R1—IPv4 and IPv6 traffic (version 9 only). |
|
PTX10001-36MR |
Junos OS Evolved 20.3R1—IPv4, IPv6, MPLS, MPLS-IPv4, and MPLS-IPv6 traffic. |
|
PTX10002-60C |
Junos OS 18.4R1—IPv4 and IPv6 traffic (both IPFIX and version 9). Junos OS 19.4R1—MPLS, MPLS-IPv4, and MPLS-IPv6 traffic. |
|
PTX10003 |
Junos OS Evolved 19.3R1—IPv4 and IPv6 traffic (IPFIX and version 9). Junos OS Evolved 20.1R1—MPLS, MPLS-IPv4, and MPLS-IPv6 traffic. |
|
PTX10004 |
Junos OS Evolved 20.4R1—IPv4, IPv6, MPLS, MPLS-IPv4, and MPLS-IPv6 traffic (IPFIX and version 9). |
|
PTX10008 (with the JNP10008-SF3 and the JNP10K-LC1201 line card) |
Junos OS Evolved 19.3R1—IPv4 and IPv6 traffic (IPFIX and version 9). Junos OS Evolved 20.1R1—MPLS, MPLS-IPv4, and MPLS-IPv6 traffic. |
|
PTX10008 (with the JNP10008-SF3 and the JNP10K-LC1202 line card) |
Junos OS Evolved 20.3R1—IPv4, IPv6, MPLS, MPLS-IPv4, and MPLS-IPv6 traffic (IPFIX and version 9). |
|
PTX10008 (without the JNP10008-SF3) and PTX10016 |
Junos OS 18.1R1—IPv4 and IPv6 traffic (both IPFIX and version 9) Junos OS 18.2R1—MPLS, MPLS-IPv4, and MPLS-IPv6 traffic. |
VRF support: Starting in Junos OS Evolved 24.2R1, we support export of IPFIX or version 9 records of inline active flow monitoring sampled packets to collectors reachable through:
-
Interfaces belonging to the mgmt_junos VRF instance.
-
WAN ports belonging to the non-default VRF instance.
You configure this feature using the routing-instance configuration
statement at the [edit forwarding-options sampling instance
name family type flow-server
IP-address] hierarchy level. You must ensure
that the collectors are reachable through the management interface. We support a
maximum of four collectors for each type of VRF instance. You can configure
collectors for both types of VRF instances in the same sampling configuration.
However, the collectors reachable through the mgmt_junos VRF instance and the
collectors reachable through the WAN ports cannot coexist under the same family,
because you can specify only one source IP address per family. You can specify
inet collectors, inet6 collectors, or a mix of
the two types.
MPLS-over-UDP support: To configure inline flow monitoring for MPLS-over UDP traffic on PTX Series Routers, see Inline Active Flow Monitoring of MPLS-over-UDP Flows on PTX Series Routers. Inline active flow monitoring for MPLS-over-UDP traffic is not supported on the PTX10001-36MR, PTX10003, PTX10004, and the PTX10008 (with the JNP10008-SF3) routers.
Collectors:
Starting in Junos OS Release 18.2R1, you can configure up to four
collectors under a family for inline active flow monitoring. In previous releases of
Junos OS, you could configure only one collector under a family for inline active
flow monitoring.
Starting
in Junos OS Evolved 20.3R1, for the PTX10003 and PTX10008 (with the JNP10K-LC1201
line card and the JNP10008-SF3) routers, you can configure up to four collectors for
inline active flow monitoring. Starting with Junos OS Evolved 20.4R1, for the
PTX10001-36MR and the PTX10008 (with the JNP10K-LC1202 line card and the
JNP10008-SF3) routers, you can configure up to four collectors for inline active
flow monitoring. Starting with Junos OS Evolved 21.1R1, for the PTX10004 router, you
can configure up to four collectors for inline active flow monitoring. To configure
a collector under a family for inline active flow monitoring, configure the
flow-server statement at the edit forwarding-options
sampling-instance instance-name family (inet | inet6)
output hierarchy level. To specify up to four collectors, include up to
four flow-server statements.
Line Card CPU: Inline active flow monitoring is implemented on the Line Card CPU (LCPU). All the functions like flow creation, flow update, and flow records export are done by the LCPU. The flow records are sent out in either the IPFIX format or the version 9 format.
Flows:
Starting with Junos OS Evolved Release 21.2R1 and Junos OS Release 21.3R1, no flows
are maintained. Every sampled packet is considered to be a flow. When the sampled
packet is received, the flow is created and immediately timed out as inactive, and
the software exports a record to the collector. Therefore, the number of records
sent to the collector is higher than before. The IPFIX and version 9 Options
Template Data Record now contains 0 in the Flow Active Timeout
(Element ID 36) and Flow Inactive Timeout (Element ID 37) fields.
Therefore, the Options Template Data Record is not compliant with IPFIX RFC 7011.
The show services accounting flow inline-jflow fpc-slot
slot operational mode command now displays 0 for
all of the Active Flows and Timed Out fields. The
values of the various Total Flows fields are now equal to their
respective Flow Packets field values. The values of the various
Flows Inactive Timed Out fields are now equal to their
respective Flow Packets field values. The effect of the
nexthop-learning statement at the [edit services
flow-monitoring version version template
template-name] hierarchy level on this no-flow
behavior varies depending upon the operating system. For Junos OS Evolved, we do not
recommend that you configure the nexthop-learning statement, as it
reduces the number of packets that can be processed. For Junos OS, you can configure
the nexthop-learning statement to change this default no-flow
behavior and once again create and maintain flows, then attach the template to all
sampling instances associated with FPCs that require the previous behavior.
Limitations and Restrictions
The following limitations and restrictions apply to the inline active flow monitoring feature in Junos OS and Junos OS Evolved:
-
Egress MPLS filters are not supported on the PTX10001-36MR, PTX10003, PTX10004, and the PTX10008 (with the JNP10008-SF3) routers.
-
The PTX10001-36MR router does not support multiple FPC sampling collection because it has only 1 Routing Engine.
-
True outgoing interface (OIF) reporting is not supported for egress sampling. In Junos OS Evolved, true outgoing interface (OIF) reporting is not supported for GRE de-encapsulated packets.
-
The interface type field for the true incoming interface is not part of the version 9 template because this element is not present in the version 9 export version.
-
For GRE tunnel traffic on PTX10003 routers, the physical interface is reported in the layer 2 header and is considered as one of the keys during flow creation. Therefore, when physical interfaces are moved in or out of the aggregated Ethernet bundle, a new flow is created and the old flows are timed out after a period of inactivity. Physical interface, logical interface, or the aggregated logical interface (based on the configuration) is reported as the incoming interface in export records based on the configuration.
For GRE tunnel traffic on PTX10008 (with the JNP10008-SF3) routers, an FTI interface is configured to terminate a GRE tunnel. This interface is used during flow creation as one of the keys instead of the physical interface. Hence when a physical interface is moved in or out of an aggregated Ethernet bundle, no new flow is created as the key remains unchanged. Physical interface, logical interface, or the aggregated logical interface (based on the configuration) is reported as the incoming interface in exported records.
How to Configure Inline Active Flow Monitoring on PTX Series Routers
SUMMARY In this example, we configure a version-ipfix template for
recording IPv4 and IPv6 traffic flows.
- Configure a Template to Specify Output Properties
- Configure a Sampling Instance to Specify Input Properties
- Assign the Sampling Instance to an FPC
- Configure a Firewall Filter to Accept and Sample Flows
- Assign the Firewall Filter to an Interface
- Results from a Sample Configuration
Configure a Template to Specify Output Properties
-
Define the template and configure the type of flow the template should record.
[edit services flow-monitoring] user@host# set version-ipfix template template-name ipv4-template user@host# set version-ipfix template template-name ipv6-template user@host# set version-ipfix template template-name mpls-template
-
(Optional) Configure additional output properties for the template, such as flow timeout interval and template/option refresh rates, to control the flow records.
You can use the
template-refresh-rateoption to configure the frequency at which the flow generator sends updates about template definitions to the flow collector either using number of packets or seconds.[edit services flow-monitoring] user@host# set version-ipfix template template-name flow-active-timeout seconds user@host# set version-ipfix template template-name flow-inactive-timeout seconds user@host# set version-ipfix template template-name template-refresh-rate (packets packets | seconds seconds) user@host# set version-ipfix template template-name option-refresh-rate (packets packets | seconds seconds)
- (Optional)
If you are monitoring MPLS flows, that is, if the template in use is configured for the MPLS protocol family, use the
tunnel-observationoption to identify the types of MPLS flows.[edit services flow-monitoring] user@host# set version-ipfix template template-name tunnel-observation (ipv4 | ipv6 | mpls-over-udp)
-
(Optional) Enable the learning of next-hop addresses so that the true outgoing interface is reported.
Note:Starting in Junos OS Evolved 21.2R1, we do not recommend that you enable learning of next-hop addresses, as it reduces the number of packets that can be processed. However, starting in Junos OS Release 21.3R1, you can configure the
nexthop-learningstatement to change the default no-flow behavior and once again create and maintain flows, then attach the template to all sampling instances associated with FPCs that require the previous behavior.[edit services flow-monitoring] user@host# set version-ipfix template template-name nexthop-learning enable
Configure a Sampling Instance to Specify Input Properties
-
Define the sampling instance and configure the ratio of number of packets to be sampled. For example, if you specify a rate of 10, every tenth packet (1 packet out of 10) is sampled.
[edit forwarding-options sampling] user@host# set instance instance-name input rate number
Best Practice:We recommend that you use a value of 1000 or higher for MPLS flows.
-
Configure the protocol family for the sampling instance and specify a flow collector to send the traffic aggregates.
[edit forwarding-options sampling] user@host# set instance instance-name family (inet | inet6 | mpls) flow-server hostname
-
(Optional) Specify the UDP port for the flow collector and the template to use with the sampling instance.
[edit forwarding-options sampling] user@host# set instance instance-name family (inet | inet6 | mpls) flow-server hostname port port-number user@host# set instance instance-name family (inet | inet6 | mpls) flow-server hostname version-ipfix template template-name
-
Configure inline processing of the sampled packets.
[edit forwarding-options sampling] user@host# set instance instance-name family (inet | inet6 | mpls) output inline-jflow source-address address
Assign the Sampling Instance to an FPC
-
Assign the sampling instance to the FPC on which you want to implement flow monitoring.
[edit chassis] user@host# set fpc slot-number sampling-instance instance-name
Configure a Firewall Filter to Accept and Sample Flows
-
Configure the firewall filter for the protocol family and enable sampling of traffic flows.
[edit firewall] user@host# set family (inet | inet6 | mpls) filter filter-name user@host# set family (inet | inet6 | mpls) filter filter-name term term-name then accept user@host# set family (inet | inet6 | mpls) filter filter-name term term-name then sample
Assign the Firewall Filter to an Interface
-
Assign the input firewall filter to the interface you want to monitor.
[edit interfaces] user@host# set interface-name unit unit-number family (inet |inet6 | mpls) filter input filter-name
Results from a Sample Configuration
The following is an example of the sampling configuration for an instance that
supports inline flow monitoring on family inet and on
family inet6:
[edit chassis]
fpc 0 {
sampling-instance sample-1;
}[edit services]
flow-monitoring {
version-ipfix {
template test-template {
flow-active-timeout 30;
flow-inactive-timeout 60;
nexthop-learning {
enable;
}
template-refresh-rate {
seconds 10;
}
ipv4-template;
}
template v6 {
ipv6-template;
}
}
}[edit interfaces]
et-1/0/0 {
unit 0 {
family inet {
filter {
input ipv4-filter;
output ipv4-filter;
}
address 192.168.100.10/24;
}
}
}
et-1/0/2 {
unit 0 {
family inet6 {
filter {
input ipv6-filter;
output ipv6-filter;
}
address 2001:db8:0:2::1/64;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.100.1/32;
}
}
}[edit forwarding-options]
sampling {
instance sample-1{
ipv4 {
input {
rate 10;
}
family inet {
output {
flow-server 10.208.174.127 {
port 2055;
version-ipfix {
template {
test-template;
}
}
}
inline-jflow {
source-address 192.168.100.1;
}
}
}
family inet6 {
output {
flow-server 10.208.174.127 {
port 2055;
version-ipfix {
template {
v6;
}
}
}
inline-jflow {
source-address 192.168.100.1;
}
}
}
}
}
}[edit firewall]
family inet {
filter ipv4-filter {
term ipv4-accept {
then {
accept;
sample;
}
}
}
}
family inet6 {
filter ipv6-filter {
term ipv6-accept {
then {
accept;
sample;
}
}
}
}You can use the show services accounting flow command to verify active flow statistics.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.