English

Flow Aggregation to Use Version 9 Flow Templates

date_range 20-Nov-18

Use of version 9 allows you to define a flow record template suitable for IPv4 traffic, IPv6 traffic, or peer AS billing traffic. Templates and the fields included in the template are transmitted to the collector periodically, and the collector need not be aware of the router configuration.

Note

Version 9 requires that you install a services PIC, such as the Adaptive Services PIC or the Multiservices PIC, in the device.

The following sections contain additional information:

Configuring the Traffic to Be Sampled

To specify sampling of IPv4, IPv6, or peer AS billing traffic, include the appropriate configuration of the family statement at the [edit forwarding-options sampling input] hierarchy level:

content_copy zoom_out_map
[edit forwarding-options sampling input]
family (inet ) {
max-packets-per-second number;
rate number;
run-length number;
}

You can include family inet.

Note

If you specify sampling for peer AS billing traffic, the family statement supports only IPv4 and IPv6 traffic (inet ). Peer AS billing traffic is enabled only at the global instance hierarchy level and is not available for per Packet Forwarding Engine instances.

Configuring the Version 9 Template Properties

To define the version 9 templates, include the following statements at the [edit services flow-monitoring version9] hierarchy level:

content_copy zoom_out_map
[edit services flow-monitoring version9]
template name {
flow-active-timeout seconds;
flow-inactive-timeout seconds;
option-refresh-rate packets packets seconds seconds;
template-refresh-rate packets packets seconds seconds;
(ipv4-template (Services) | ipv6-template (Services) |
mpls-ipv4-template | mpls-template | peer-as-billing-template) {
label-position [ positions ];
}
}

The following details apply to the configuration statements:

You assign each template a unique name by including the template name statement.
You then specify each template for the appropriate type of traffic by including the ipv4-template, ipv6–template, inet-ipv4-template, inet-template, or peer-as-billing-template.
If the template is used for inet traffic, you can also specify up to three label positions for the inet header label data by including the label-position statement; the default values are [1 2 3].
Within the template definition, you can optionally include values for the flow-active-timeout and flow-inactive-timeout statements. These statements have specific default and range values when they are used in template definitions; the default is 60 seconds and the range is from 10 through 600 seconds. Values you specify in template definitions override the global timeout values configured at the [edit forwarding-options sampling output flow-server] hierarchy level.

Note
In active flow monitoring, the flow-server records are exported after a time period that is a multiple of 60 seconds and greater than or equal to the configured active timeout value. For example, if the active timeout value is 90 seconds, the flow-server records are exported at 120-second intervals. If the active timeout value is 150 seconds, the flow-server records are exported at 180-second intervals, and so forth.
You can also include settings for the option-refresh-rate and template-refresh-rate statements within a template definition. For both of these properties, you can include a timer value (in seconds) or a packet count (in number of packets). For the seconds option, the default value is 60 and the range is from 10 through 600. For the packets option, the default value is 4800 and the range is from 1 through 480,000.
To filter IPV6 traffic on a media interface, the following configuration is supported:

interfaces interface-name {
unit 0 {
family inet {
sampling {
input;
output;
}
}
}
}

Restrictions

The following restrictions apply to version 9 templates:

You cannot apply the two different types of flow aggregation configuration (flow-server version 5/8 and flow aggregation version 9) at the same time.
Flow export based on an inet-ipv4 template assumes that the IPv4 header follows the inet header. In the case of Layer 2 VPNs, the packet on the provider router (P router) would look like this:

inet | Layer 2 Header | IPv4

In this case, inet-ipv4 flows are not created on the PIC, because the IPv4 header does not directly follow the inet header. Packets are dropped on the PIC and are accounted as parser errors.
Outbound Routing Engine traffic is not sampled. A firewall filter is applied as output on the egress interface, which samples packets and exports the data. For transit traffic, egress sampling works correctly. For internal traffic, the next hop is installed in the Packet Forwarding Engine but sampled packets are not exported.
Flows are created on the monitoring PIC only after the route record resynchronization operation is complete, which is 60 seconds after the PIC comes up. Any packets sent to the PIC would be dropped until the synchronization process is complete.

On SRX300, SRX320, SRX340, SRX345, and SRX550HM devices, flow monitoring IPv6 version 9 has the following limitations:

MPLS in not supported.
User-defined version 9 templates are not supported.
Routing Engine based flow monitoring version 9 is not supported.
Flow monitoring and accounting are not supported in chassis cluster mode.
Flow monitoring and accounting are not supported on an ae interface.
J-Web for IPv6 sampled packets is not supported.
SNMP queries for IPv6 sampled packets are not supported
Flow monitoring can be configured in version 5, version 8, or version 9 export mode. Up to eight version 9 collectors are supported in export mode.
Scope of accounting of IPv6 flow monitoring version 9 packets associated with pseudointerfaces (such as IRB, ML, LAG, VLAN, and GRE) is not supported.
Creation of an SCTP session (parallel to TCP) between an exporter and a collector for gathering flow monitoring information is not supported.
Maximum flow sessions that might be supported include:
- A device with 1-GB RAM, such as an SRX320 device, might support up to 15,000 flow monitoring sessions at a time.
- A device with 2-GB RAM, such as an SRX650 device, might support up to 59,900 flow monitoring sessions at a time.
Note
Platform support depends on the Junos OS release in your installation.
Routing Engine based flow monitoring V5 or V8 mode is mutually exclusive with inline flow monitoring V9.
SRX5400, SRX5600, and SRX5800 do not support multiple collectors like SRX300, SRX320, SRX340, SRX345, and SRX550HM devices. Only one V9 collector per IPv4 or IPv6 is supported
Flow aggregation for V9 export is not supported.
Only UDP over IPv4 or IPv6 protocol can be used as the transport protocol.
Only the standard IPv4 or IPv6 template is supported for exporting flow monitoring records.
User-defined or special templates are not supported for exporting flow monitoring records.
Chassis cluster is supported without flow monitoring session synchronization.

Fields Included in Each Template Type

The following fields are common to all template types:

Input interface
Output interface
Number of bytes
Number of packets
Flow start time
Flow end time

The IPv4 template includes the following specific fields:

IPv4 Source Address
IPv4 Destination Address
L4 Source Port
L4 Destination Port
IPv4 TOS
IPv4 Protocol
ICMP type and code
TCP Flags
Application Id
Direction
IPv4 Next Hop Address

The IPv6 template includes the following specific fields:

IPv6 Source Address and Mask
IPv6 Destination Address and Mask
L4 Source Port
L4 Destination Port
IPv6 TOS
IPv6 Protocol
TCP Flags
Application Id
Direction
IP Protocol Version
IPv6 Next Hop Address
Egress Interface Information
Source Autonomous System (AS) number
Destination AS number

The inet template includes the following specific fields:

inet Label #1
inet Label #2
inet Label #3
inet EXP Information
FEC IP Address

The inet-IPv4 template includes all the fields found in the IPv4 and inet templates.

The peer AS billing template includes the following specific fields:

IPV4 Class of Service (TOS)
Ingress Interface
BGP IPV4 Next Hop Address
BGP Peer Destination AS Number

inet Sampling Behavior

This section describes the behavior when inet sampling is used on egress interfaces in various scenarios (label pop or swap) on provider routers (P routers).

You configure inet sampling on an egress interface on the P router and configure an inet flow aggregation template. The route action is label pop because penultimate hop popping (PHP) is enabled.
Previously, IPv4 packets (only) would have been sent to the PIC for sampling even though you configured inet sampling. No flows should be created, with the result that the parser fails.
With the current capability of applying inet templates, inet flows are created.
As in the first case, you configure inet sampling on an egress interface on the P router and configure an inet flow aggregation template. The route action is label swap and the swapped label is 0 (explicit null).
The resulting behavior is that inet packets are sent to the PIC. The flow being sampled corresponds to the label before the swap.
You configure a Layer 3 VPN network, in which a customer edge router (CE-1) sends traffic to a provider edge router (PE-A), through the P router, to a similar provider edge router (PE-B) and customer edge router (CE-2) on the remote end.
The resulting behavior is that you cannot sample inet packets on the PE-A to P router link.

Verification

To verify the configuration properties, you can use the show services accounting aggregation template template-name name operational mode command.

All other show services accounting commands also support version 9 templates, except for show services accounting flow-detail and show services accounting aggregation aggregation-type.

Examples: Configuring Version 9 Flow Templates

The following is a sample version 9 template configuration:

content_copy zoom_out_map
services {
flow-monitoring {
version9 {
template ip-template {
flow-active-timeout 20;
flow-inactive-timeout 120;
ipv4-template;
}
template inet-template-1 {
inet-template {
label-position [1 3 4];
}
}
template inet-ipv4-template-1 {
inet-ipv4-template {
label-position [1 5 7];
}
}
template peer-as-billing-template-1 {
peer-as-billing-template;
}
}
}
}
}

The following is a sample firewall filter configuration for inet traffic:

content_copy zoom_out_map
firewall {
family inet {
filter inet_sample {
term default {
then {
accept;
sample;
}
}
}
}
}

The following sample configuration applies the inet sampling filter on a networking interface and configures the AS PIC to accept both IPv4 and inet traffic:

content_copy zoom_out_map
inline-jflows {
at-0/1/1 {
unit 0 {
family inet {
filter {
input inet_sample;
}
}
}
}
sp-7/0/0 {
unit 0 {
family inet;
family inet;
}
}
}

The following example applies the inet version 9 template to the sampling output and sends it to the AS PIC:

content_copy zoom_out_map
forwarding-options {
sampling {
input {
family inet {
rate 1;
}
}
output {
flow-active-timeout 60;
flow-inactive-timeout 30;
flow-server 1.2.3.4 {
port 2055;
version9 {
template inet-ipv4-template-1;
}
}
inline-jflow sp-7/0/0 {
source-address 1.1.1.1;
}
}
}
}

The following is a sample firewall filter configuration for the peer AS billing traffic:

content_copy zoom_out_map
firewall {
family inet {
filter peer-as-filter {
term 0 {
from {
destination-class dcu-1;
inline-jflow ge-2/1/0;
forwarding-class class-1;
}
then count count_team_0;
}
}
term 1 {
from {
destination-class dcu-2;
inline-jflow ge-2/1/0;
forwarding-class class-1;
}
then count count_team_1;
}
term 2 {
from {
destination-class dcu-3;
inline-jflow ge-2/1/0;
forwarding-class class-1;
}
then count count_team_2;
}
}
}
}

The following sample configuration applies the firewall filter as a filter attribute under the forwarding-options hierarchy for CoS-level data traffic usage information collection:

content_copy zoom_out_map
forwarding-options {
family inet {
filter output peer-as-filter;
}
}

The following example applies the peer-as-billing version 9 template to enable sampling of traffic for billing purposes:

content_copy zoom_out_map
forwarding-options {
sampling {
}
input {
rate 1;
}
family inet {
output {
flow-server 10.209.15.58 {
port 300;
version9 {
template {
peer-as;
}
}
}
inline-jflow sp-5/2/0 {
source-address 2.3.4.5;
}
}
}
}
}
family inet {
filter {
output peer-as-filter;
}
}

ON THIS PAGE