Configuring Flow Aggregation on MX, M, vMX and T Series Routers and NFX250 to Use Version 9 Flow Templates
Use of version 9 flow template enables you to define a flow record template suitable for IPv4 traffic, IPv6 traffic, MPLS traffic, a combination of IPv4 and MPLS traffic, or peer AS billing traffic. Templates and the fields included in the template are transmitted to the collector periodically, and the collector does not affect the router configuration.
Version 9 requires that you install a services PIC, such as the Adaptive Services PIC or MS-PIC in the router. On MX Series routers, the MS-DPC fulfills this requirement. For more information on determining which services PIC is suitable for your router, see Enabling Service Packages or the appropriate hardware documentation.
If multiple protocol families are configured for a particular flow collector, the export packets originates from multiple Source IDs, with each Source ID corresponding to a particular protocol. The multiple Source IDs do not indicate that the export packets are originating from multiple Service PICs.
Configuring the Traffic to Be Sampled
To specify sampling of IPv4, IPv6,
MPLS, or peer AS billing traffic, include the appropriate configuration
of the family statement at the [edit forwarding-options
sampling] hierarchy level:
[edit forwarding-options]
sampling {
family (inet | inet6 | mpls);
}
You can include family inet ,family inet6, or family mpls.
If you specify sampling for peer AS billing traffic, the family statement supports only IPv4 and IPv6 traffic (inet
or inet6). Peer AS billing traffic is enabled only at the global instance
hierarchy level and is not available for per Packet Forwarding Engine
instances.
After you specify the family of traffic to be sampled, configure the sampling parameters such as:
Maximum packet length (beyond which the packets are truncated).
Maximum packets to be sampled per second (beyond which the packets are dropped).
Rate (for example, if you specify 10, every 10th packet is sampled).
Run length (which specifies the number of packets to be sampled after the trigger; that is, if the
rateis set to 10 andrun-lengthto 5, five packets starting at the 10th packet are sampled).
[edit forwarding-options sampling]
input {
maximum-packet-length bytes
max-packets-per-second number;
rate number;
run-length number;
}
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:
[edit services flow-monitoring version9] template template-name { options-template-id template-id source-id flow-active-timeout seconds; flow-inactive-timeout seconds; option-refresh-rate packets packets seconds seconds; template-refresh-rate packets packets seconds seconds; (ipv4-template | ipv6-template | 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 template-namestatement.You then specify each template for the appropriate type of traffic by including the
ipv4-template,ipv6-template,mpls-ipv4-template, ormpls-template.If the template is used for MPLS traffic, you can also specify up to three label positions for the MPLS header label data by including the
label-positionstatement; the default values are[1 2 3].Within the template definition, you can optionally include values for the
flow-active-timeoutandflow-inactive-timeoutstatements. 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 family (inet | inet6 | mpls) output flow-server]hierarchy level.You can also include settings for the
option-refresh-rateandtemplate-refresh-ratestatements 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 thesecondsoption, the default value is 60 and the range is from 10 through 600. For thepacketsoption, 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 inet6 { sampling { input; output; } } } }
Customizing Template ID, Observation Domain ID, and Source ID for Version 9 Flow Templates
Starting in Junos OS Release 14.1, you can define a Version 9 flow record template suitable for IPv4 traffic, IPv6 traffic, MPLS traffic, a combination of IPv4 and MPLS traffic, or peer AS billing traffic. Templates and the fields included in the template are transmitted to the collector periodically,and the collector does not affect the router configuration. You can specify the unique identifier for the version 9 and IPFIX templates. The identifier of a template is locally unique within a combination of a transport session and an observation domain. Template IDs 0 through 255 are reserved for template sets, options template sets, and other sets for future use. Template IDs of data sets are numbered from 256 through 65535. Typically, this information element or field in the template is used to define the characteristics or properties of other information elements in a template. After a restart of the export process of templates is performed, you can reassign template IDs.
This functionality to configure template ID, options template ID, observation domain ID, and source ID is supported on all routers with MPCs.
The template IDs that include MPLS and MPLS-IPv4 template ID are applicable for IPFIX only. The V9 format carries a different template ID.
The corresponding data sets and option data sets contain the value of the template IDs and options template IDs respectively in the set ID field. This method enables the collector to match a data record with a template record.
For more information about specifying the source ID, observation domain ID, template ID, and options template ID for version 9 and IPFIX flows, see Configuring Observation Domain ID and Source ID for Version 9 and IPFIX Flows and Configuring Template ID and Options Template ID for Version 9 and IPFIX Flows.
Restrictions
The following restrictions apply to version 9 templates:
You cannot apply the two different types of flow aggregation configuration at the same time.
Flow export based on an
mpls-ipv4template assumes that the IPv4 header follows the MPLS header. In the case of Layer 2 VPNs, the packet on the provider router (P router) looks like this:MPLS | Layer 2 Header | IPv4
In this case,
mpls-ipv4flows are not created on the PIC, because the IPv4 header does not directly follow the MPLS 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 are dropped until the synchronization process is complete.
Because the forwarding of a packet that arrives with MPLS labels is performed based on the MPLS label and not based on the IP address contained in the packet, the packet is sampled at the output interface with the MPLS label that was popped not being available at the time of sampling. In such a case, depending on the incoming interface (IIF), the VRF index is identified and the route for the sampled packet is determined in the VRF table. Because a specific route is not available in the VRF that is different from the VRF on which the packet is received, the Output Interface Index, Source Mask, and Destination Mask fields are incorrectly populated. This behavior occurs when an IPv4 template is applied as a firewall filter on an egress interface with sample as the action.
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
IPv4 Next Hop Address
Source autonomous system (AS) number
Destination AS number
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
IP Protocol Version
IPv6 Next Hop Address
Egress Interface Information
Source Autonomous System (AS) number
Destination AS number
The MPLS template includes the following specific fields:
MPLS Label #1
MPLS Label #2
MPLS Label #3
MPLS EXP Information
FEC IP Address
The MPLS-IPv4 template includes all the fields found in the IPv4 and MPLS 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
MPLS Sampling Behavior
This section describes the behavior when MPLS sampling is used on egress interfaces in various scenarios (label pop or swap) on provider routers (P routers). For more information on configuration and background specific to MPLS applications, see the MPLS Applications User Guide.
You configure MPLS sampling on an egress interface on the P router and configure an MPLS flow aggregation template. The route action is label pop because penultimate hop popping (PHP) is enabled.
With the current capability of applying MPLS templates, MPLS flows are created.
As in the first case, you configure MPLS sampling on an egress interface on the P router and configure an MPLS flow aggregation template. The route action is label swap and the swapped label is 0 (explicit null).
The resulting behavior is that MPLS 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 MPLS 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. For more information about operational mode commands, see the CLI Explorer.
Examples: Configuring Version 9 Flow Templates
The following example shows a version 9 template configuration:
services {
flow-monitoring {
version9 {
template ip-template {
flow-active-timeout 20;
flow-inactive-timeout 120;
ipv4-template;
}
template mpls-template-1 {
mpls-template {
label-position [1 3 4];
}
}
template mpls-ipv4-template-1 {
mpls-ipv4-template {
label-position [1 5 7];
}
}
template vpls-template-1 {
vpls-template;
}
}
}
}
}
The following example shows a firewall filter configuration for MPLS traffic:
firewall {
family mpls {
filter mpls_sample {
term default {
then {
accept;
sample;
}
}
}
}
}
The following example applies the MPLS sampling filter on a networking interface and configures the AS PIC to accept both IPv4 and MPLS traffic:
interfaces {
at-0/1/1 {
unit 0 {
family mpls {
filter {
input mpls_sample;
}
}
}
}
sp-7/0/0 {
unit 0 {
family inet;
family mpls;
}
}
}
The following example applies the MPLS version 9 template to the sampling output and sends it to the AS PIC:
forwarding-options {
sampling {
input {
family mpls {
rate 1;
}
}
family mpls {
output {
flow-active-timeout 60;
flow-inactive-timeout 30;
flow-server 192.0.2.4 {
port 2055;
version9 {
template mpls-ipv4-template-1;
}
}
interface sp-7/0/0 {
source-address 198.51.100.1;
}
}
}
}
}
The following example shows a firewall filter configuration for the peer AS billing traffic:
firewall {
family inet {
filter peer-as-filter {
term 0 {
from {
destination-class dcu-1;
interface ge-2/1/0;
forwarding-class class-1;
}
then count count_team_0;
}
}
term 1 {
from {
destination-class dcu-2;
interface ge-2/1/0;
forwarding-class class-1;
}
then count count_team_1;
}
term 2 {
from {
destination-class dcu-3;
interface ge-2/1/0;
forwarding-class class-1;
}
then count count_team_2;
}
}
}
}
The following example applies the peer AS firewall filter as a filter attribute under the forwarding-options hierarchy for CoS-level data traffic usage information collection:
forwarding-options {
family inet {
filter output peer-as-filter;
}
}
The following example applies the peer AS DCU policy options to collect usage statistics for the traffic stream for as-path ingressing at a specific input interface with the firewall configuration hierarchy applied as Forwarding Table Filters (FTFs). The configuration functionality with CoS capability can be achieved through FTFs for destination-class usage with forwarding-class for specific input interfaces:
policy-options {
policy-statement P1 {
from {
protocol bgp;
neighbor 10.2.25.5; #BGP router configuration;
as-path AS-1; #AS path configuration;
}
then destination-class dcu-1; #Destination class configuration;
}
policy-statement P2 {
from {
neighbor 203.0.113.5;
as-path AS-2;
}
then destination-class dcu2;
}
policy-statement P3 {
from {
protocol bgp;
neighbor 192.0.2.129;
as-path AS-3;
}
then destination-class dcu3;
}
as-path AS-1 3131:1111:1123;
as-path AS-2 100000;
as-path AS-3 192:29283:2;
}
The following example applies the vpls version 9 template to enable sampling of traffic for billing purposes:
forwarding-options {
sampling {
}
input {
rate 1;
}
family inet {
output {
flow-server 10.209.15.58 {
port 300;
version9 {
template {
peer-as;
}
}
}
interface sp-5/2/0 {
source-address 203.0.113.133;
}
}
}
}
}
family inet {
filter {
output peer-as-filter;
}
}
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.