# 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 <a href="#id-35555f44-a73d-4f74-8dee-0525bd366512" id="id-35555f44-a73d-4f74-8dee-0525bd366512"></a>

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 <a href="#f618a4b5-bff1-4c60-830b-f9a146a6aa15" id="f618a4b5-bff1-4c60-830b-f9a146a6aa15"></a>

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 <a href="#id-2e1b2abb-96a5-45dc-a0d7-4389ba268cfe" id="id-2e1b2abb-96a5-45dc-a0d7-4389ba268cfe"></a>

* 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 href="#ad0a0af2-ca78-453f-b8db-4cac9dfefcb6" id="ad0a0af2-ca78-453f-b8db-4cac9dfefcb6"></a>

* 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&#x20;**_**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 <a href="#id-41308146-48b1-4372-9f0f-6a3608bf2f0f" id="id-41308146-48b1-4372-9f0f-6a3608bf2f0f"></a>

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:

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FLO2XxgFvFfhXmRf18Rcm%2FUntitled.png?alt=media&#x26;token=3706d5a7-af2f-4b5f-a520-7966d2038db8" alt=""><figcaption></figcaption></figure>



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:

<table data-header-hidden><thead><tr><th width="152"></th><th width="141"></th><th width="191"></th><th></th></tr></thead><tbody><tr><td><strong>Food item</strong></td><td><strong>Number Sold</strong></td><td><strong>Number on Order</strong></td><td><strong>Number in Inventory</strong></td></tr><tr><td>Apple</td><td>10</td><td>300</td><td>43</td></tr><tr><td>Banana</td><td>39</td><td>510</td><td>239</td></tr></tbody></table>



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 <a href="#id-9bf66d11-f305-4b6b-8fe1-795f84cb9f55" id="id-9bf66d11-f305-4b6b-8fe1-795f84cb9f55"></a>

[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/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.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://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](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](https://thwack.solarwinds.com/search?q=netflow-v9-datagram-knowledge-series)
