Netflow (IOS-XE)

On CSR1, configure Netflow for IPv4 using the following guidelines:

• Match on the default 7 fields, and also gather information about payload length and the TTL value

• Sample 1 in 50 packets

• Export netflow data to a collector at 1.1.1.1 over netflow v9

• Send the template every 60 seconds

• Active flows should timeout after 600 seconds, and inactive flows should timeout after 20 seconds

• Apply this to traffic ingressing and egressing Gi2.12

Answer

flow record RECORD1
 match ipv4 destination address
 match ipv4 source address
 match ipv4 protocol
 match transport source-port
 match transport destination-port
 match ipv4 tos
 match interface input
 collect ipv4 length payload
 collect ipv4 ttl
!
sampler SAMPLER1
 mode random 1 out-of 50
!
flow exporter EXPORTER1
 destination 1.1.1.1
 export-protocol netflow-v9 
 template data timeout 60
!
flow monitor MONITOR1
 exporter EXPORTER1
 cache timeout inactive 20
 cache timeout active 600
 record RECORD1
!
int Gi2.12
 ip flow monitor MONITOR1 sampler SAMPLER1 input
 ip flow monitor MONITOR1 sampler SAMPLER1 output

Explanation

Netflow is used to capture statistics about traffic ingressing/egressing and interface, without performing a full packet capture/SPAN session. Netflow can be used to bill based on usage, plan network capacitiy, and aid in security analysis.

In Netflow, a summary of the traffic is sent to a collector, instead of sending the actual packet. For example, the headers of the packet, size of the packet, etc. is reported to the collector.

Netflow is composed of four components:

• Flow records, which define key and nonkey fields

  • Key fields (match) define the flow

  • Nonkey fields (collect) define information to gather about each flow

• Flow exporters define the exporting of flow records

• Flow monitors tie together the record and exporter, and are applied to an interface

• Samplers ease burden of the router by only collecting netflow data on a percentage of traffic passing through the router

By default, a flow is categorized based on seven keys:

• Src/Dst IP

• Src/Dst port

• IP protocol

• ToS byte

• Input interface

For this reason, we define these as match fields (key fields) in our flow record. The collect fields are fields to collect, but which do not define a flow.

For example, the payload length is gathered for all packets in the flow, and exported as a total bytes captured for the flow. This is a “collect” field, so it does not define the flow.

flow record RECORD1
 match ipv4 destination address
 match ipv4 source address
 match ipv4 protocol
 match transport source-port
 match transport destination-port
 match ipv4 tos
 match interface input
 collect ipv4 length payload
 collect ipv4 ttl

Note that you do not have to use your own record. You can instead use the basic flow record by using:

flow monitor X
 record netflow ipv4|ipv6 original-input

Next you define an exporter. Here you can define the VRF, export-protocol (usually v9 or IPFIX), source interface, and DSCP value.

flow exporter EXPORTER1
 destination 1.1.1.1 [vrf NAME]
 export-protocol netflow-v9 

In netflow v9 and IPFIX, a flexible format is used, in which a template record describes the template. Flow records are “lightweight,” because they simply contain the data itself with a reference to the previously sent template record. This means that a collector cannot use the data until it sees the template record. We can control how often the router exports the template records using the following command:

flow exporter EXPORTER1
 template data timeout 60

The exporter and record are tied together using a flow monitor. This is where you can also define the cache timeout values. The active timeout value is how long to wait until finally timing out an active flow and exporting the data. The inactive timeout value is how long to wait after a flow is inactive before exporting the data.

flow monitor MONITOR1
 exporter EXPORTER1
 cache timeout inactive 20
 cache timeout active 600
 record RECORD1

This is tied to an interface, along with an optional sampler.

sampler SAMPLER1
 mode random 1 out-of 50
!
int Gi2.12
 ip flow monitor MONITOR1 sampler SAMPLER1 input
 ip flow monitor MONITOR1 sampler SAMPLER1 output

Note that for IPv6, you would need a separate monitor that matches on ipv6 fields and you would apply this to the interface as follows:

flow monitor IPV6
 record netflow ipv6 original-input
 exporter EXPORTER1
!
int gi2
 ipv6 flow monitor IPV6 input
 ipv6 flow monitor IPV6 output