Netflow

This article assumes the reader has some familiarity with Netflow. Most engineers working towards CCNP-SP will have already encoutered this feature, so this article can serve as a refresher.

In a nutshell, Netflow is a protocol developed by Cisco which collects IP flow information. A router classifies flows based on matching fields of an IP packet, and exports statistics about these flows to an external Netflow collector. You can use Netflow to bill based on usage and examine which hosts are using up the most bandwidth in your network.

In general, flexible Netflow using v9 or IPFIX is used these days, so we won’t cover the older versions. IPFIX is an IETF standard which is based on Cisco’s version 9.

Flows

In Netflow, a flow is categorized based, by default, on seven “keys”

1. Source IP

2. Destination IP

3. Source port

4. Destination port

5. Layer 3 protocol type

6. ToS byte

7. Input interface (the interface on which the packet arrived)

Packets which match on all seven of these fields are considered part of the same flow. A flow is unidirectional (each direction is a separate flow because the IPs and ports are flipped).

In addition to these key fields, you can gather other information from the packet. The fields you can gather are called nonkey fields. Nonkey fields do not define flows, instead these fields are collected for each flow and exported with the flow information to the netflow collector. These fields include:

• Source or Destination AS (autonomous system)

• IP next hop address

• Source or Destination netmask

• TCP flags

• Bytes or packets in the flow

• Timestamp of the first and last packet of the flow

Configuration - IOS-XE

To configure flexible netflow, you configure four separate components.

1. You optionally configure flow records. These are the combination of key fields which will define a flow, and nonkey fields which define which extra data to capture and export along with each flow.

   On IOS-XE there are a number of predefined records that you can use. You can examine them with the command show flow record. For this reason it is optional to configure your own flow records. You can simply use a pre-existing flow record instead.

   Router#show flow record
   flow record netflow-original:
     Description:        Traditional IPv4 input NetFlow with origin ASs
     No. of users:       0
     Total field space:  53 bytes
     Fields:
       match ipv4 tos
       match ipv4 protocol
       match ipv4 source address
       match ipv4 destination address
       match transport source-port
       match transport destination-port
       match interface input
       match flow sampler
       collect routing source as
       collect routing destination as
       collect routing next-hop address ipv4
       collect ipv4 source mask
       collect ipv4 destination mask
       collect transport tcp flags
       collect interface output
       collect counter bytes
       collect counter packets
       collect timestamp sys-uptime first
       collect timestamp sys-uptime last

   • match fields are keys which define the flow

   • collect fields are nonkeys which are captured for each flow

   You can see a list of default preconfigured records on the router:

   Router#show flow record | in flow record
   flow record netflow-original:
   flow record netflow ipv4 original-input:
   flow record netflow ipv4 original-input peer:
   flow record netflow ipv4 original-output:
   flow record netflow ipv4 original-output peer:
   flow record netflow ipv4 as:
   flow record netflow ipv4 as peer:
   flow record netflow ipv4 as-tos:
   flow record netflow ipv4 as-tos peer:
   flow record netflow ipv4 assurance:
   flow record netflow ipv4 assurance-rtp:
   flow record netflow ipv4 bgp-nexthop-tos:
   flow record netflow ipv4 bgp-nexthop-tos peer:
   flow record netflow ipv4 destination-prefix:
   flow record netflow ipv4 destination-prefix peer:
   flow record netflow ipv4 destination-prefix-tos:
   flow record netflow ipv4 destination-prefix-tos peer:
   flow record netflow ipv4 prefix:
   flow record netflow ipv4 prefix peer:
   flow record netflow ipv4 prefix-port:
   flow record netflow ipv4 prefix-tos:
   flow record netflow ipv4 prefix-tos peer:
   flow record netflow ipv4 protocol-port:
   flow record netflow ipv4 protocol-port-tos:
   flow record netflow ipv4 source-prefix:
   flow record netflow ipv4 source-prefix peer:
   flow record netflow ipv4 source-prefix-tos:
   flow record netflow ipv4 source-prefix-tos peer:
   flow record netflow ipv6 original-input:
   flow record netflow ipv6 original-input peer:
   flow record netflow ipv6 original-output:
   flow record netflow ipv6 original-output peer:
   flow record netflow ipv6 as:
   flow record netflow ipv6 as peer:
   flow record netflow ipv6 assurance:
   flow record netflow ipv6 assurance-rtp:
   flow record netflow ipv6 bgp-nexthop:
   flow record netflow ipv6 bgp-nexthop peer:
   flow record netflow ipv6 destination-prefix:
   flow record netflow ipv6 destination-prefix peer:
   flow record netflow ipv6 prefix:
   flow record netflow ipv6 prefix peer:
   flow record netflow ipv6 protocol-port:
   flow record netflow ipv6 source-prefix:
   flow record netflow ipv6 source-prefix peer:

   You can also define your own flow record:

   flow record my-flow-record
    match <fields>
    collect <fields>

2. You must define a flow exporter. This is the destination of the netflow collector to which you will send netflow information. You do not send the actual packets to the collector, as in a pcap. Instead you send information about each flow such as the IP addresses, ports, and the fields you are collecting (tcp flags, etc.). This information is sent once the flow has stopped, or if the flow is long-lived, once the active timer has expired.

   flow exporter my-flow-exporter
    destination ip-address
    export-protocol netflow-v5|netflow-v9|ipfix
    transport udp port

3. Optionally you can define a sampler which eases CPU burden. This is used to sample only a percent of traffic going through the interface instead of examing every single packet. This limits the number of packets that the router has to analyze.

   sampler my-sampler
    mode random 1 out-of <2-32768>

4. You must tie the flow record and flow exporter together with a flow monitor. The flow monitor is what is applied to the interface.

   flow monitor my-flow-monitor
    record my-flow-record 
    exporter my-flow-exporter
   !
   int Gi1
    ip flow monitor my-flow-monitor [sample my-sampler] input|output

Trivia Facts for IOS-XE

• Up to ten exporters can be configured in a single flow monitor. Each flow exporter can only have a single destination though.

• TCP and UDP are supposedly both supported as an export protocol, but on CSR1000v I only see an option for UDP

• Export of fields obtained from NBAR is only supported when using IPFIX

• When applying a flow monitor in the egress direction on an interface that is in a VRF, you cannot collect the destination mask, destination prefix, destination AS, nexthop, or BGP nexthop

• You can use layer 2 fields such as vlan ID and mac address

• You can set the DSCP value on packets exported to the collector under the flow exporter configuration

Netflow on IOS-XR

• A source interface must be configured under the flow exporter

• Netflow v5 is not supported

• UDP is the only supported export protocol

• You can only apply one flow monitor to an interface per direction for flow monitors which record MPLS labels.

On IOS-XR you cannot create your own flow record. You are limited to the following options:

• record ipv4 [peer as]

  • To collect and export the peer AS you must have bgp attribute-download configured.

    router bgp 100
     address-family ipv4 unicast
      bgp attribute-download

• record ipv6

• record mpls [ipv4-fields]|[ipv6-fields]|[ipv4-ipv6-fields] [labels num]

  • Max labels number is 6 deep

Configuration on IOS-XR is very similar to IOS-XE:

1. Configure a flow exporter

   flow exporter-map my-flow-exporter
    destination 1.1.1.1
    source lo0
    transport udp port
    version v9|ipfix

2. Optionally create a sampler-map

   sampler-map my-sampler-map
    random 1 out-of <1-65535>

3. Configure a monitor map and apply to the interface

   flow monitor-map my-flow-monitor
    record ipv4|ipv6|mpls
    exporter my-flow-exporter
   !
   int Gi0/0/0/0
    flow ipv4 monitor my-flow-monitor sampler my-sampler-map ingress|egress

The main difference between IOS-XR and IOS-XE is that you cannot configure your own flow record in IOS-XR.

Templates

The following information is not necessary to have the ability to configure netflow, but it is useful to understand how netflow v9 works.

Netflow v9 (and IPFIX) are template based, which provides an extensible format to flow records.

A flowset is used to convey a template format or a flow record. A flow record is a packet that is sent when a flow has ended. It contains all the information about that single flow. A template record defines each field that a flow record will use. A flow record points to a template record’s ID so that the collector can decode it.

Take a look at this pcap, obtained from Nick Russo’s website:

Flowset1 is a template flowset. It contains a template ID which is 256. The template record defines what each field in a flow record will mean and the position of each field. Flowset2 is a record flowset. It has the actual data of a flow. This particular flow was 29 packets over TCP/23. The flow points to the template via the FlowSet ID field. This is how wireshark is able to decode the packet.

A netflow collector must cache all template records it receives in order to be able to correlate new flow records to their template record in the future. A router does not need to include the template record in each flow record it sends. A packet can simply be a list of flow records. It’s the collector’s job to cache the template in order to decode future flow records.

An analogy to this is that the template record is the top “header” row of a spreadsheet, and flow records are all the subsequent rows of data.

For example, let’s say I have this table:

Food item	Number Sold	Number on Order	Number in Inventory
Apple	10	300	43
Banana	39	510	239

The template record is like sending the top row plus a unique ID:

food_item, num_sold, num_on_order, num_in_inventory, id=13

Each line of data can be sent by itself with just a reference to the template:

apple, 10, 300, 43, id=13

Because Netflow v9 does not used a fixed-template format, it can always be extended in the future.

Further Reading

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fnetflow/configuration/xe-17/fnf-xe-17-book/fnf-fnetflow.html

https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r6-5/netflow/configuration/guide/b-netflow-cg-asr9k-65x/b-netflow-cg-asr9k-65x_chapter_010.html

https://www.youtube.com/watch?v=TZUW5lqzZDc&ab_channel=solarwindsinc

https://thwack.solarwinds.com/resources/b/geek-speak/posts/netflow-v9-datagram-knowledge-series-part-4---netflow-v9-data-flowset

• The links to other posts in this series seem to be dead. The easiest way to view them is to use the search bar like this: https://thwack.solarwinds.com/search?q=netflow-v9-datagram-knowledge-series