Configuring Flow Aggregation to Use Version 9 Flow Templates
Use of version 9 allows 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 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 Multiservices PIC in the router. On MX Series routers, the Multiservices 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. |
The following sections contain additional information:
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 input] hierarchy level:
You can include family inet ,family inet6, or family mpls.
| Note: 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. |
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:
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, mpls-ipv4-template, mpls-template, or peer-as-billing-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.
Note: In active flow monitoring, the cflowd 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 cflowd records are exported at 120-second intervals. If the active timeout value is 150 seconds, the cflowd 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 inet6 {sampling {input;output;}}}}
Restrictions
The following restrictions apply to version 9 templates:
- You cannot apply the two different types of flow aggregation configuration (cflowd version 5/8 and flow aggregation version 9) 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) would look like
this: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 would be 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 Junos OS MPLS Applications Configuration 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.
Previously, IPv4 packets (only) would have been sent to the PIC for sampling even though you configured MPLS sampling. No flows should be created, with the result that the parser fails.
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 is a sample version 9 template configuration:
The following is a sample firewall filter configuration for MPLS traffic:
The following sample configuration applies the MPLS sampling filter on a networking interface and configures the AS PIC to accept both IPv4 and MPLS traffic:
The following example applies the MPLS version 9 template to the sampling output and sends it to the AS PIC:
The following is a sample firewall filter configuration for the peer AS billing traffic:
The following sample configuration applies the peer AS firewall filter as a filter attribute under the forwarding-options hierarchy for CoS-level data traffic usage information collection:
The following sample configuration 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:
The following example applies the peer-as-billing version 9 template to enable sampling of traffic for billing purposes:
