Configuring Flow Aggregation on MX, M, vMX and T Series Routers and NFX250 to Use Version 9 Flow Templates

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.

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 rate is set to 10 and run-length to 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-name statement.

• You then specify each template for the appropriate type of traffic by including the ipv4-template, ipv6-template, mpls-ipv4-template, or mpls-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-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 family (inet | inet6 | mpls) output flow-server] hierarchy level.

• 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:

  content_copy zoom_out_map

  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 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-ipv4 template 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:

  content_copy zoom_out_map

  MPLS | Layer 2 Header | IPv4
  

  In this case, mpls-ipv4 flows 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.

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;
    }
}