> For the complete documentation index, see [llms.txt](https://docs.bindplane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bindplane.com/integrations/sources/netflow.md). # NetFlow The NetFlow source listens on a UDP port for flow records exported by routers, switches, and other network devices, and decodes them into structured logs. It supports the NetFlow and sFlow schemes, processes NetFlow v5, v9, and IPFIX messages, and reads [Template Records](https://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9.html) when present. Mapping of custom fields is not yet supported. ### Supported Telemetry | Platform | Metrics | Logs | Traces | | -------- | ------- | ---- | ------ | | Linux | | ✓ | | | Windows | | ✓ | | | macOS | | ✓ | | ### Prerequisites This source is a protocol listener, so the prerequisites are network-side: * The exporting devices (routers, switches, or sFlow/NetFlow agents) must be configured to send flow records to the collector's IP address on the listen port (default UDP `2055`). * The listen port must be reachable: open it in any host firewall and in cloud network security groups or firewall rules between the exporters and the collector. * Binding to a port below 1024 requires the collector to run with elevated privileges (root on Linux/macOS, Administrator on Windows). The default port `2055` is above 1024 and does not require elevation. * The `scheme` you select must match what the devices export: choose `netflow` for NetFlow v5/v9 and IPFIX, or `sflow` for sFlow. ### Configuration
Bindplane docs - NetFlow - image 1
| Parameter | Type | Required | Default | Description | | --------------------- | -------------------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------- | | Choose Telemetry Type | Telemetry Selector | No | Logs | The signal this source emits. Only Logs is supported. | | Scheme | Enum: netflow, sflow | No | netflow | The type of flow data to receive. | | Hostname | String | No | 0.0.0.0 | The hostname or IP address to bind to. | | Port | Integer | No | 2055 | The port to bind to. | | Sockets | Integer | No | 1 | The number of sockets to use. | | Workers | Integer | No | 1 | The number of workers used to decode incoming flow messages. | | Send Raw | Boolean | No | false | Whether the collector should parse flow messages into attributes or send them as a raw string in the body. | ### Examples #### Receive NetFlow v9/IPFIX on the default port This source binds to all interfaces on the default NetFlow port and decodes incoming records into structured logs. ```yaml apiVersion: bindplane.observiq.com/v1 kind: Source metadata: name: netflow spec: type: netflow parameters: - name: scheme value: netflow - name: hostname value: 0.0.0.0 - name: port value: 2055 ``` #### Receive sFlow and forward the raw payload This source listens for sFlow records and sends each message as a raw string in the log body instead of parsing it into attributes. ```yaml apiVersion: bindplane.observiq.com/v1 kind: Source metadata: name: netflow spec: type: netflow parameters: - name: scheme value: sflow - name: port value: 6343 - name: send_raw value: true ``` ### Configuration Tips * Set `scheme` to match the exporting devices. NetFlow v5/v9 and IPFIX use the `netflow` scheme; sFlow uses the `sflow` scheme. A mismatch causes incoming datagrams to fail to decode. * Keep `hostname` as `0.0.0.0` to accept records on all interfaces, or set a specific address to bind to a single interface. * Increase `sockets` and `workers` for high flow-record volume so the collector can keep up with decoding. Start at `1` each and raise as needed. * Enable `send_raw` only when a downstream processor expects the unparsed flow payload. The default (`false`) decodes records into structured attributes. ### Troubleshooting #### No logs arriving Symptoms: the source is running but no flow records appear in the pipeline. Solutions: 1. Confirm the exporting devices are pointed at the collector's IP and the configured port. 2. Verify the listen port (default UDP `2055`) is open in host and cloud firewalls between the exporters and the collector. 3. Confirm `scheme` matches what the devices export (`netflow` vs `sflow`). #### Permission denied binding the port Symptoms: the collector fails to start and logs a permission or bind error on the listen port. Solutions: 1. Ports below 1024 require root (Linux/macOS) or Administrator (Windows). Run the collector with elevated privileges or use a port above 1024, such as the default `2055`. #### Records arrive but are not decoded Symptoms: datagrams reach the collector but logs are empty or malformed. Solutions: 1. Verify the `scheme` matches the export protocol. 2. For NetFlow v9/IPFIX, confirm the exporter is sending Template Records; the decoder needs them to interpret the data records that follow. ### Standalone Source ```yaml apiVersion: bindplane.observiq.com/v1 kind: Source metadata: name: netflow spec: type: netflow parameters: - name: scheme value: netflow - name: hostname value: 0.0.0.0 - name: port value: 2055 - name: sockets value: 1 - name: workers value: 1 - name: send_raw value: false ``` ### Related Resources * [NetFlow receiver — OpenTelemetry Collector Contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/netflowreceiver) * [Cisco NetFlow Template Records white paper](https://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9.html) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.bindplane.com/integrations/sources/netflow.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.