> For the complete documentation index, see [llms.txt](https://docs.onum.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.onum.com/listeners/listener-integrations/collect-data-from-cisco-netflow.md).

# Collect data from Cisco NetFlow

{% hint style="info" %}
See the changelog of the **Cisco NetFlow** Listener [here](/listeners-changelog/cisco-netflow-listener.md).
{% endhint %}

{% hint style="warning" %}
The **Cisco NetFlow** Listener is a **Pull** Listener and therefore should not be used in environments with more than one cluster.
{% endhint %}

## Overview

Onum supports integration with [Cisco NetFlow](https://www.cisco.com/site/us/en/index.html).

Cisco NetFlow is a network protocol developed by Cisco for collecting and analyzing IP network traffic data. It enables network administrators to understand traffic patterns, identify potential issues, and optimize network performance.

## Cisco NetFlow setup

In order to begin listening for data, you must first:

* Enable IP routing&#x20;
* Enable Cisco Express Forwarding (CEF)

See the [Cisco Netflow configuration guide](https://www.cisco.com/c/dam/en/us/td/docs/security/stealthwatch/netflow/Cisco_NetFlow_Configuration.pdf) for help with this.

## Onum setup

{% stepper %}
{% step %}
Log in to your Onum tenant and click **Listeners > New listener**.
{% endstep %}

{% step %}
Double-click the **Cisco NetFlow** Listener.
{% endstep %}

{% step %}
Enter a **Name** for the new Listener. Optionally, add a **Description** and some **Tags** to identify the Listener.
{% endstep %}

{% step %}
In the **Socket** section, enter the following:

* **Transport protocol** - Currently, Onum only supports the UDP protocol.
* **Port** - Enter the required IP port number. By default, **Cisco NetFlow** typically uses UDP port `2055` for exporting flow data.
  {% endstep %}

{% step %}
Configure the **Flow** parameters:

* **Protocols to process** - Select the required protocol(s) from the list:
  * `NetflowV5` is the most widely used version.
  * `NetflowV9`  is more customizable than v5.
  * `IPFIX` is based on the IPFIX standard (IP Flow Information Export).
  * `sFlowv5` is another flow monitoring protocol that is typically used in high-speed networks.
* **Fields to include** - Select all the fields you wish to include in the output data.&#x20;

{% hint style="warning" %}
Field selection should match the fields actually present in your data. Selecting non-existing fields will result in `null` values and may cause unexpected behavior.\
\
[Check the table below](#proposed-field-sets) for safe field sets proposals for each protocol.
{% endhint %}
{% endstep %}

{% step %}
Choose your **Access control type** to selectively monitor traffic based on specific IPs:

* **None** - allows all IPs.
* **Whitelist** - allows certain IPs through.
* **Blacklist** - blocks certain IPs from being captured or exported.
  {% endstep %}

{% step %}
Enter the **IPs** you wish to apply the access control to. Click **Add element** to add as many as required.
{% endstep %}

{% step %}
Finally, click **Create labels**. Optionally, you can set labels to be used for internal Onum routing of data. By default, data will be set as **Unlabeled**.

{% hint style="info" %}
Learn more about labels in [this article](/listeners/labels.md).
{% endhint %}
{% endstep %}

{% step %}
Click **Create listener** when you're done.
{% endstep %}
{% endstepper %}

### Proposed field sets

Check the following table for recommended safe field sets per protocol (NetflowV5, NetflowV9, IPFIX and sFlowv5). We recommend using as a baseline to work from rather than selecting all available fields by default.

{% hint style="warning" %}
For NetflowV9 and IPFIX, since both are template-based protocols, the safe field set will always depend on the fields declared in the exporter's template.&#x20;

As a general rule, only select fields that you have confirmed are present in your exporter's template. Selecting fields not declared in the template will result in those fields decoding as `null` and may cause unexpected behavior during Listener recovery or restart.
{% endhint %}

<table><thead><tr><th width="190.78125"></th><th></th></tr></thead><tbody><tr><td><code>NetflowV5</code></td><td><p>NetflowV5 has a completely fixed format with no templates, meaning the following fields are always present and safe to use in any standard implementation:<br></p><ul><li><code>SrcAddr</code></li><li><code>DstAddr</code></li><li><code>SrcPort</code></li><li><code>DstPort</code></li><li><code>Proto</code></li><li><code>Bytes</code></li><li><code>Packets</code></li><li><code>TimeFlowStart</code></li><li><code>TimeFlowEnd</code></li><li><code>InIf</code></li><li><code>OutIf</code></li><li><code>IPTos</code></li><li><code>SequenceNum</code></li><li><code>SamplingRate</code></li><li><code>SamplerAddress</code></li><li><code>TimeReceived</code></li></ul></td></tr><tr><td><code>NetflowV9</code></td><td><p>NetflowV9 is dynamic and depends on the template declared by the exporter. The fields most commonly exported by standard Cisco devices and considered safe as a baseline are:<br></p><ul><li><code>SrcAddr</code></li><li><code>DstAddr</code></li><li><code>SrcPort</code></li><li><code>DstPort</code></li><li><code>Proto</code></li><li><code>Bytes</code></li><li><code>Packets</code></li><li><code>TimeFlowStart - flowStartMilliseconds</code></li><li><code>TimeFlowEnd - flowEndMilliseconds</code></li><li><code>InIf</code></li><li><code>OutIf</code></li><li><code>IPTos</code></li><li><code>SequenceNum</code></li><li><code>SamplerAddress</code></li><li><code>TimeReceived</code></li></ul><p><br>These groups of fields that should not be selected unless explicitly declared in the exporter's template:<br></p><ul><li><code>MPLS</code></li><li><code>PPP</code></li><li><code>encap</code></li><li><code>IPv6</code></li><li><code>VLAN</code></li><li><code>MAC</code></li><li><code>Fragment</code></li><li><code>VRF</code></li></ul></td></tr><tr><td><code>IPFIX</code></td><td><p>Like NetflowV9, IPFIX is template-based. The recommended core safe fields are practically the same:</p><p></p><ul><li><code>SrcAddr</code></li><li><code>DstAddr</code></li><li><code>SrcPort</code></li><li><code>DstPort</code></li><li><code>Proto</code></li><li><code>Bytes</code></li><li><code>Packets</code></li><li><code>TimeFlowStart</code></li><li><code>TimeFlowEnd</code></li><li><code>InIf</code></li><li><code>OutIf</code></li><li><code>IPTos</code></li><li><code>SequenceNum</code></li><li><code>SamplerAddress</code></li><li><code>TimeReceived</code></li></ul></td></tr><tr><td><code>sFlowv5</code></td><td><p>sFlow is a sampling protocol with a different structure to NetFlow. The most commonly available fields are:</p><p></p><ul><li><code>SrcAddr</code></li><li><code>DstAddr</code></li><li><code>SrcPort</code></li><li><code>DstPort</code></li><li><code>Proto</code></li><li><code>Bytes</code></li><li><code>Packets</code></li><li><code>InIf</code></li><li><code>OutIf</code></li><li><code>TimeReceived</code></li><li><code>SamplingRate</code></li><li><code>SamplerAddress</code></li></ul></td></tr></tbody></table>

## Output Ports <a href="#ports" id="ports"></a>

The **Cisco NetFlow** Listener has only a single output port:

* **Default port** - Events are sent through this port if no error occurs while processing them.
