IPFIX
Synopsis
Creates an IPFIX collector that accepts flow data over UDP connections. Supports high-volume collection with multiple worker processes. Also handles NetFlow v9 templates.
For details, see Appendix.
Schema
- id: <numeric>
name: <string>
description: <string>
type: ipfix
tags: <string[]>
pipelines: <pipeline[]>
status: <boolean>
properties:
address: <string>
port: <numeric>
workers: <numeric>
reuse: <boolean>
Configuration
The following fields are used to define the device:
Device
| Field | Required | Default | Description |
|---|---|---|---|
id | Y | Unique identifier | |
name | Y | Device name | |
description | N | - | Optional description |
type | Y | Must be ipfix | |
tags | N | - | Optional tags |
pipelines | N | - | Optional pre-processor pipelines |
status | N | true | Enable/disable the device |
Connection
| Field | Required | Default | Description |
|---|---|---|---|
address | N | "0.0.0.0" | Listen address |
port | N | 4739 | Listen port |
workers | N | CPU count | Number of worker goroutines |
reuse | N | false | Enable socket address reuse |
Details
NetFlow, sFlow, and IPFIX devices share a common flow collection backend (backend/module/listener/flow/). The thin per-protocol controller sets the flow type and default port.
When reuse is enabled, the collector automatically scales to use multiple workers based on available CPU cores. Each worker maintains its own UDP listener, processes flows independently, and writes to a dedicated queue file.
The collector supports template management for NetFlow v9 and IPFIX, application identification, port-based protocol mapping, flow state tracking, and statistical aggregation.
Examples
The following are commonly used configuration types.
Basic
Creating a simple IPFIX collector on the default port... | |
High-Volume
Optimizing for high flow volumes using multiple workers... | |
When reuse is enabled, the collector automatically scales up to use all available CPU cores.
IPFIX collector with application identification enabled... | |