netflow_parser
A Netflow Parser library for Cisco V5, V7, V9, and IPFIX written in Rust. Supports chaining of multiple versions in the same stream.
⚠️ Multi-Router Deployments: Use
AutoScopedParserinstead ofNetflowParserwhen parsing from multiple routers to prevent template cache collisions. See Template Management Guide for details.
Table of Contents
- Example
- Serialization (JSON)
- Filtering for a Specific Version
- Iterator API
- Parser Configuration
- Netflow Common
- Re-Exporting Flows
- V9/IPFIX Notes
- Template Management Guide
- Performance & Thread Safety
- Features
- Included Examples
Example
V5
use ;
// 0000 00 05 00 01 03 00 04 00 05 00 06 07 08 09 00 01 ................
// 0010 02 03 04 05 06 07 08 09 00 01 02 03 04 05 06 07 ................
// 0020 08 09 00 01 02 03 04 05 06 07 08 09 00 01 02 03 ................
// 0030 04 05 06 07 08 09 00 01 02 03 04 05 06 07 08 09 ................
// 0040 00 01 02 03 04 05 06 07 ........
let v5_packet = ;
let result = default.parse_bytes;
match result.packets.first
// Check for errors
if let Some = result.error
Want Serialization such as JSON?
Structures fully support serialization. Below is an example using the serde_json macro:
use json;
use NetflowParser;
// 0000 00 05 00 01 03 00 04 00 05 00 06 07 08 09 00 01 ................
// 0010 02 03 04 05 06 07 08 09 00 01 02 03 04 05 06 07 ................
// 0020 08 09 00 01 02 03 04 05 06 07 08 09 00 01 02 03 ................
// 0030 04 05 06 07 08 09 00 01 02 03 04 05 06 07 08 09 ................
// 0040 00 01 02 03 04 05 06 07 ........
let v5_packet = ;
let result = default.parse_bytes;
println!;
Filtering for a Specific Version
use ;
// 0000 00 05 00 01 03 00 04 00 05 00 06 07 08 09 00 01 ................
// 0010 02 03 04 05 06 07 08 09 00 01 02 03 04 05 06 07 ................
// 0020 08 09 00 01 02 03 04 05 06 07 08 09 00 01 02 03 ................
// 0030 04 05 06 07 08 09 00 01 02 03 04 05 06 07 08 09 ................
// 0040 00 01 02 03 04 05 06 07 ........
let v5_packet = ;
let result = default.parse_bytes;
let v5_parsed: = result.packets.into_iter.filter.collect;
Iterator API
You can use the iterator API to process packets one-by-one as they're parsed instead of returning Vec:
use ;
let buffer = /* your netflow data */;
let mut parser = default;
// Process packets without collecting into a Vec
for packet_result in parser.iter_packets
The iterator provides access to unconsumed bytes for advanced use cases:
use NetflowParser;
let buffer = /* your netflow data */;
let mut parser = default;
let mut iter = parser.iter_packets;
while let Some = iter.next
// Check if all bytes were consumed
if !iter.is_complete
Benefits of Iterator API
- Zero allocation: Packets are yielded one-by-one without allocating a
Vec - Memory efficient: Ideal for processing large batches or continuous streams
- Lazy evaluation: Only parses packets as you consume them
- Template caching preserved: V9/IPFIX template state is maintained across iterations
- Composable: Works with standard Rust iterator methods (
.filter(),.map(),.take(), etc.) - Buffer inspection: Access unconsumed bytes via
.remaining()and check completion with.is_complete()
Iterator Examples
// Count V5 packets without collecting
let count = parser.iter_packets
.filter
.count;
// Process only the first 10 packets
for packet in parser.iter_packets.take
// Collect only if needed (equivalent to parse_bytes())
let packets: = parser.iter_packets.collect;
// Check unconsumed bytes (useful for mixed protocol streams)
let mut iter = parser.iter_packets;
for packet in &mut iter
if !iter.is_complete
Parser Configuration
The NetflowParser can be configured using the builder pattern to customize behavior for your specific use case.
Basic Builder Usage
use NetflowParser;
// Create parser with default settings
let parser = default;
// Or use the builder for custom configuration
let parser = builder
.build
.expect;
Template Cache Size
V9 and IPFIX parsers use LRU (Least Recently Used) caching to store templates. Configure the cache size to prevent memory exhaustion while maintaining good performance:
use NetflowParser;
// Configure both V9 and IPFIX parsers with the same cache size
let parser = builder
.with_cache_size // Default is 1000
.build
.expect;
// Configure V9 and IPFIX independently
let parser = builder
.with_v9_cache_size
.with_ipfix_cache_size
.build
.expect;
Cache Behavior:
- When the cache is full, the least recently used template is evicted
- Templates are keyed by template ID (per source)
- Each parser instance maintains its own template cache
- For multi-source deployments, use
RouterScopedParser(see Template Management section)
Maximum Field Count (Security)
Configure the maximum number of fields allowed per template to prevent DoS attacks via malicious packets with excessive field counts:
use NetflowParser;
// Configure both V9 and IPFIX parsers with the same limit
let parser = builder
.with_max_field_count // Default is 10,000
.build
.expect;
// Configure V9 and IPFIX independently
let parser = builder
.with_v9_max_field_count
.with_ipfix_max_field_count
.build
.expect;
Security Considerations:
- Default limit: 10,000 fields per template (accommodates legitimate use cases)
- Malicious packets claiming 65,535 fields will be rejected
- Templates exceeding the limit return a parse error
- Lower limits provide stricter security but may reject valid templates
- Higher limits are more permissive but increase DoS risk
Additional Security Validations: The parser also automatically validates:
- Template Total Size: Maximum sum of all field lengths per template (default: u16::MAX = 65,535 bytes)
- Prevents DoS attacks via templates with excessive total field lengths
- Configurable via
Config::max_template_total_size
- Duplicate Field Detection: Templates with duplicate field IDs are rejected
- For V9: Validates unique
field_type_numbervalues - For IPFIX: Validates unique
(field_type_number, enterprise_number)pairs - Catches malformed or corrupted template definitions
- For V9: Validates unique
Template TTL (Time-to-Live)
⚠️ Breaking Change in v0.7.0: Packet-based and combined TTL modes have been removed. Only time-based TTL is now supported. See RELEASES.md for migration guide.
Optionally configure templates to expire after a time duration. This is useful for:
- Handling exporters that reuse template IDs with different schemas
- Forcing periodic template refresh from exporters
- Testing template re-learning behavior
Note: TTL is disabled by default. Templates persist until LRU eviction unless explicitly configured.
use NetflowParser;
use TtlConfig;
use Duration;
// Templates expire after 2 hours
let parser = builder
.with_cache_size
.with_ttl
.build
.unwrap;
// Using default TTL (2 hours)
let parser = builder
.with_cache_size
.with_ttl
.build
.unwrap;
// Different TTL for V9 and IPFIX
let parser = builder
.with_v9_ttl
.with_ipfix_ttl
.build
.unwrap;
Filtering Versions
If you only care about specific NetFlow versions, configure allowed versions:
use NetflowParser;
// Only parse V5 and V9 packets
let parser = builder
.with_allowed_versions
.build
.expect;
// Or set directly on an existing parser
let mut parser = default;
parser.allowed_versions = .into;
Packets with versions not in the allowed list will be ignored (returns empty Vec).
Error Handling & ParseResult
parse_bytes() returns ParseResult to preserve partially parsed packets when errors occur mid-stream:
use ;
let result = parser.parse_bytes;
// Always get successfully parsed packets, even if an error occurred later
for packet in result.packets
// Check for errors
if let Some = result.error
iter_packets() yields Result<NetflowPacket, NetflowError> for per-packet error handling:
// Per-packet error handling
for result in parser.iter_packets
Error types: Incomplete, UnsupportedVersion, Partial, MissingTemplate, ParseError. All implement Display and std::error::Error.
Error Sample Size Configuration
To prevent memory exhaustion from malformed packets, the parser limits the size of error buffer samples. By default, only the first 256 bytes of unparseable data are stored in error messages:
use NetflowParser;
// Recommended: Use builder pattern (automatically configures all parsers)
let parser = builder
.with_max_error_sample_size // Default is 256 bytes
.build
.expect;
// Or configure directly on an existing parser (requires manual sync)
let mut parser = default;
parser.max_error_sample_size = 512;
parser.v9_parser.max_error_sample_size = 512;
parser.ipfix_parser.max_error_sample_size = 512;
This setting helps prevent memory exhaustion when processing malformed or malicious packets while still providing enough context for debugging.
Migration Guide
From 0.7.x to 0.8.0
What changed: Two major improvements to error handling:
- ParseResult -
parse_bytes()now returnsParseResultto preserve partial results on errors - Error Handling -
NetflowPacket::Errorvariant removed, errors now useResult
ParseResult (prevents data loss):
// ❌ Old (0.7.x) - loses packets 1-4 if packet 5 errors
let packets = parser.parse_bytes; // Returns Vec<NetflowPacket>
// Silent error: if parsing stopped at packet 5, you lost packets 1-4
// ✅ New (0.8.0) - keep packets 1-4 even if packet 5 errors
let result = parser.parse_bytes; // Returns ParseResult
for packet in result.packets
if let Some = result.error
Error Handling (use Result instead of Error variant):
// ❌ Old (0.7.x) - errors inline with packets
for packet in parser.parse_bytes
// ✅ New (0.8.0) - use iter_packets() for Result-based errors
for result in parser.iter_packets
Custom Enterprise Fields (IPFIX)
IPFIX supports vendor-specific enterprise fields that extend the standard IANA field set. The library provides built-in support for several vendors (Cisco, VMWare, Netscaler, etc.), but you can also register your own custom enterprise fields:
use NetflowParser;
use FieldDataType;
use EnterpriseFieldDef;
// Register custom enterprise fields for your vendor
let parser = builder
.register_enterprise_field
.register_enterprise_field
.build
.expect;
// Parse IPFIX packets - custom fields are automatically decoded!
let packets = parser.parse_bytes;
Bulk Registration
use NetflowParser;
use FieldDataType;
use EnterpriseFieldDef;
let custom_fields = vec!;
let parser = builder
.register_enterprise_fields
.build
.expect;
Available Data Types
When registering enterprise fields, you can use any of these built-in data types:
FieldDataType::UnsignedDataNumber- Unsigned integers (variable length)FieldDataType::SignedDataNumber- Signed integers (variable length)FieldDataType::Float64- 64-bit floating pointFieldDataType::String- UTF-8 stringsFieldDataType::Ip4Addr- IPv4 addressesFieldDataType::Ip6Addr- IPv6 addressesFieldDataType::MacAddr- MAC addressesFieldDataType::DurationSeconds- Durations in secondsFieldDataType::DurationMillis- Durations in millisecondsFieldDataType::DurationMicrosNTP- NTP microsecond timestampsFieldDataType::DurationNanosNTP- NTP nanosecond timestampsFieldDataType::ProtocolType- Protocol numbersFieldDataType::Vec- Raw byte arraysFieldDataType::ApplicationId- Application identifiers
How It Works:
- Without registration: Unknown enterprise fields are parsed as raw bytes (
FieldValue::Vec) - With registration: Registered enterprise fields are automatically parsed according to their specified data type
- Field names: The
nameparameter is used for debugging and can help identify fields in logs
See examples/custom_enterprise_fields.rs for a complete working example.
Complete Configuration Example
use NetflowParser;
use TtlConfig;
use FieldDataType;
use EnterpriseFieldDef;
use Duration;
let parser = builder
// Cache configuration
.with_v9_cache_size
.with_ipfix_cache_size
// Security limits
.with_v9_max_field_count
.with_ipfix_max_field_count
.with_max_error_sample_size
// Template TTL
.with_v9_ttl
.with_ipfix_ttl
// Version filtering
.with_allowed_versions
// Enterprise fields
.register_enterprise_fields
// Template lifecycle hooks
.on_template_event
.build
.expect;
// For multi-source deployments, use AutoScopedParser instead:
// let scoped_parser = NetflowParser::builder()./* config */.multi_source();
Netflow Common
We have included a NetflowCommon and NetflowCommonFlowSet structure.
This will allow you to use common fields without unpacking values from specific versions.
If the packet flow does not have the matching field it will simply be left as None.
NetflowCommon and NetflowCommonFlowSet Struct:
use IpAddr;
use ProtocolTypes;
Converting NetflowPacket to NetflowCommon
use ;
// 0000 00 05 00 01 03 00 04 00 05 00 06 07 08 09 00 01 ................
// 0010 02 03 04 05 06 07 08 09 00 01 02 03 04 05 06 07 ................
// 0020 08 09 00 01 02 03 04 05 06 07 08 09 00 01 02 03 ................
// 0030 04 05 06 07 08 09 00 01 02 03 04 05 06 07 08 09 ................
// 0040 00 01 02 03 04 05 06 07 ........
let v5_packet = ;
let result = default.parse_bytes;
let netflow_common = result.packets
.first
.unwrap
.as_netflow_common
.unwrap;
for common_flow in netflow_common.flowsets.iter
Flattened flowsets
To gather all flowsets from all packets into a flattened vector:
use NetflowParser;
let flowsets = default.parse_bytes_as_netflow_common_flowsets;
Custom Field Mappings for V9 and IPFIX
By default, NetflowCommon maps standard IANA fields to the common structure. However, you can customize which fields are used for V9 and IPFIX packets using configuration structs. This is useful when:
- You want to prefer IPv6 addresses over IPv4
- Your vendor uses non-standard field mappings
- You need to extract data from vendor-specific enterprise fields
V9 Custom Field Mapping
use ;
use V9Field;
// Create a custom configuration that prefers IPv6 addresses
let mut config = default;
config.src_addr.primary = Ipv6SrcAddr;
config.src_addr.fallback = Some;
config.dst_addr.primary = Ipv6DstAddr;
config.dst_addr.fallback = Some;
// Use with a parsed V9 packet
// let common = NetflowCommon::from_v9_with_config(&v9_packet, &config);
IPFIX Custom Field Mapping
use ;
use ;
// Create a custom configuration that prefers IPv6 addresses
let mut config = default;
config.src_addr.primary = IANA;
config.src_addr.fallback = Some;
config.dst_addr.primary = IANA;
config.dst_addr.fallback = Some;
// Use with a parsed IPFIX packet
// let common = NetflowCommon::from_ipfix_with_config(&ipfix_packet, &config);
Available Configuration Fields
Both V9FieldMappingConfig and IPFixFieldMappingConfig support configuring:
| Field | Description | Default V9 Field | Default IPFIX Field |
|---|---|---|---|
src_addr |
Source IP address | Ipv4SrcAddr (fallback: Ipv6SrcAddr) | SourceIpv4address (fallback: SourceIpv6address) |
dst_addr |
Destination IP address | Ipv4DstAddr (fallback: Ipv6DstAddr) | DestinationIpv4address (fallback: DestinationIpv6address) |
src_port |
Source port | L4SrcPort | SourceTransportPort |
dst_port |
Destination port | L4DstPort | DestinationTransportPort |
protocol |
Protocol number | Protocol | ProtocolIdentifier |
first_seen |
Flow start time | FirstSwitched | FlowStartSysUpTime |
last_seen |
Flow end time | LastSwitched | FlowEndSysUpTime |
src_mac |
Source MAC address | InSrcMac | SourceMacaddress |
dst_mac |
Destination MAC address | InDstMac | DestinationMacaddress |
Each field mapping has a primary field (always checked first) and an optional fallback field (used if primary is not present in the flow record).
Re-Exporting Flows
Parsed V5, V7, V9, and IPFIX packets can be re-exported back into bytes.
V9/IPFIX Padding Behavior:
- For parsed packets: Original padding is preserved exactly for byte-perfect round-trips
- For manually created packets: Padding is automatically calculated to align FlowSets to 4-byte boundaries
Creating Data Structs:
For convenience, use Data::new() and OptionsData::new() to create data structures without manually specifying padding:
use Data;
// Padding is automatically set to empty vec and calculated during export
let data = new;
See examples/manual_ipfix_creation.rs for a complete example of creating IPFIX packets from scratch.
use ;
// 0000 00 05 00 01 03 00 04 00 05 00 06 07 08 09 00 01 ................
// 0010 02 03 04 05 06 07 08 09 00 01 02 03 04 05 06 07 ................
// 0020 08 09 00 01 02 03 04 05 06 07 08 09 00 01 02 03 ................
// 0030 04 05 06 07 08 09 00 01 02 03 04 05 06 07 08 09 ................
// 0040 00 01 02 03 04 05 06 07 ........
let packet = ;
let result = default.parse_bytes;
if let Some = result.packets.first
V9/IPFIX Notes
Parse the data (&[u8]) like any other version. The parser (NetflowParser) caches parsed templates using LRU eviction, so you can send header/data flowset combos and it will use the cached templates. Templates are automatically cached and evicted when the cache limit is reached.
Template Management: For comprehensive information about template caching, introspection, multi-source deployments, and best practices, see the Template Management Guide section below.
IPFIX Note: We only parse sequence number and domain id, it is up to you if you wish to validate it.
FlowSet Access: To access templates flowset of a processed V9/IPFIX flowset you can find the flowsets attribute on the Parsed Record. In there you can find Templates, Option Templates, and Data Flowsets.
Template Management Guide
Overview
NetFlow V9 and IPFIX are template-based protocols where templates define the structure of flow records. This library provides comprehensive template management features to handle various deployment scenarios.
Template Cache Metrics
Track template cache performance to understand your parser's behavior:
use NetflowParser;
let mut parser = default;
// Parse some packets...
parser.parse_bytes;
// Get cache statistics
let v9_stats = parser.v9_cache_stats;
println!;
// Access performance metrics
let metrics = &v9_stats.metrics;
println!;
println!;
println!;
println!;
println!;
// Calculate hit rate
if let Some = metrics.hit_rate
Metrics tracked:
- Hits: Successful template lookups
- Misses: Failed template lookups (template not in cache)
- Evictions: Templates removed due to LRU policy when cache is full
- Collisions: Template ID reused with a different definition (same ID, different schema)
- Note: RFC-compliant template retransmissions (same ID, same definition) are NOT counted as collisions
- Expired: Templates removed due to TTL expiration
Multi-Source Deployments (RFC-Compliant)
⚠️ IMPORTANT: When parsing from multiple routers, template IDs collide. Different routers often use the same template ID (e.g., 256) with completely different schemas, causing cache thrashing and parsing failures.
The Problem:
// ❌ DON'T: Multiple sources sharing one parser
let mut parser = default;
loop
The Solution - Use AutoScopedParser:
// ✅ DO: Each source gets isolated template cache (RFC-compliant)
use AutoScopedParser;
use SocketAddr;
let mut parser = new;
// Parser automatically handles RFC-compliant scoping:
// - NetFlow v9: Uses (source_addr, source_id) per RFC 3954
// - IPFIX: Uses (source_addr, observation_domain_id) per RFC 7011
// - NetFlow v5/v7: Uses source_addr only
let source: SocketAddr = "192.168.1.1:2055".parse.unwrap;
let packets = parser.parse_from_source;
// Monitor cache health
if parser.source_count > 1
Why AutoScopedParser?
- Prevents template collisions - Each source has isolated cache
- RFC-compliant - Follows NetFlow v9 (RFC 3954) and IPFIX (RFC 7011) scoping rules
- Automatic - No manual key management required
- Better performance - Higher cache hit rates, no thrashing
Advanced: Custom Scoping with RouterScopedParser
For specialized requirements beyond automatic RFC-compliant scoping, use RouterScopedParser with custom key types:
use RouterScopedParser;
use SocketAddr;
// Example: Custom scoping for named sources
let mut scoped = new;
scoped.parse_from_source;
// Example: Manual composite key (not recommended - use AutoScopedParser instead)
let mut scoped = new;
When to use RouterScopedParser instead of AutoScopedParser:
- You need custom scoping logic beyond protocol standards
- You're using named identifiers for sources
- You have application-specific grouping requirements
For standard NetFlow/IPFIX deployments, use AutoScopedParser instead.
Custom Parser Configuration
Configure parsers with custom settings:
use ;
use TtlConfig;
use Duration;
// Configure AutoScopedParser
let builder = builder
.with_cache_size
.with_ttl;
let mut parser = with_builder;
// Or configure RouterScopedParser for custom scoping
use RouterScopedParser;
let mut scoped = with_builder;
Template Collision Detection
Monitor when template IDs are reused with different definitions:
let v9_stats = parser.v9_cache_stats;
if v9_stats.metrics.collisions > 0
What counts as a collision:
- Same template ID with a different definition (field structure changed)
- This typically indicates multiple routers using the same template ID for different schemas
What does NOT count as a collision:
- Retransmitting the same template (same ID, identical definition)
- RFC 7011 (IPFIX) and RFC 3954 (NetFlow v9) recommend periodic template retransmission for reliability
- Template refreshes are normal and expected behavior
Handling Missing Templates
When a data flowset arrives before its template (IPFIX):
use ;
use FlowSetBody;
let mut parser = default;
let mut pending_data = Vecnew;
for packet in parser.iter_packets
// Retry pending data after templates arrive
for pending in &pending_data
Template Lifecycle Management
Template Introspection
Inspect the template cache state at runtime without affecting LRU ordering:
use NetflowParser;
let parser = default;
// Get cache statistics
let v9_stats = parser.v9_cache_stats;
println!;
let ipfix_stats = parser.ipfix_cache_stats;
println!;
// List all cached template IDs
let v9_templates = parser.v9_template_ids;
println!;
let ipfix_templates = parser.ipfix_template_ids;
println!;
// Check if a specific template exists (doesn't affect LRU ordering)
if parser.has_v9_template
Clearing Templates
// Clear all V9 templates
parser.clear_v9_templates;
// Clear all IPFIX templates
parser.clear_ipfix_templates;
// With RouterScopedParser - clear specific source
scoped_parser.clear_source_templates;
// Or clear all sources
scoped_parser.clear_all_templates;
Best Practices
-
Use AutoScopedParser for multi-source deployments ⭐
- Automatically implements RFC-compliant scoping
- Prevents template ID collisions between sources and observation domains
- No manual key management required
- Correct for all NetFlow/IPFIX versions
-
Monitor cache metrics
- High miss rates indicate templates arriving out of order
- High collision rates suggest need for scoped parsing (if not using AutoScopedParser)
- High eviction rates indicate cache size should be increased
-
Configure appropriate cache size
- Default: 1000 templates per source
- Increase for routers that define many templates
- Monitor
current_sizevsmax_sizeto right-size
-
Use TTL for long-running parsers
- Prevents stale templates in 24/7 collectors
- Recommended: 1-2 hours for typical deployments
- See Template TTL section
-
Handle missing templates gracefully
- Cache data flowsets that arrive before templates
- Retry after template packets are processed
- Use
NoTemplateInfoto understand what's missing
-
Thread safety with scoped parsers
AutoScopedParserandRouterScopedParserare not thread-safe- Use
Arc<Mutex<AutoScopedParser>>for multi-threaded applications - See Thread Safety for details
Performance & Thread Safety
Thread Safety
Parsers (NetflowParser, V9Parser, IPFixParser) are not thread-safe and should not be shared across threads without external synchronization. Each parser maintains internal state (template caches) that is modified during parsing.
Recommended pattern for multi-threaded applications:
- Create one parser instance per thread
- Each thread processes packets from a single router/source
- See
examples/netflow_udp_listener_multi_threaded.rsfor implementation example
Performance Optimizations
This library includes several performance optimizations:
- Single-pass field caching - NetflowCommon conversions use efficient single-pass lookups
- Minimal cloning - Template storage avoids unnecessary vector clones
- Optimized string processing - Single-pass filtering and prefix stripping
- Capacity pre-allocation - Vectors pre-allocate when sizes are known
- Bounded error buffers - Error handling limits memory consumption to prevent exhaustion
Best practices for optimal performance:
- Reuse parser instances instead of creating new ones for each packet
- Use
iter_packets()instead ofparse_bytes()when you don't need all packets in a Vec - Use
parse_bytes_as_netflow_common_flowsets()when you only need flow data - For V9/IPFIX, batch process packets from the same source to maximize template cache hits
Features
parse_unknown_fields- When enabled fields not listed in this library will attempt to be parsed as a Vec of bytes and the field_number listed. When disabled an error is thrown when attempting to parse those fields. Enabled by default.netflow_common- When enabled providesNetflowCommonandNetflowCommonFlowSetstructures for working with common fields across different Netflow versions. Disabled by default.
Included Examples
Examples have been included mainly for those who want to use this parser to read from a Socket and parse netflow. In those cases with V9/IPFix it is best to create a new parser for each router. There are both single threaded and multi-threaded examples in the examples directory.
Examples that listen on a specific port use 9995 by default, however netflow can be configurated to use a variety of URP ports:
- 2055: The most widely recognized default for NetFlow.
- 9995 / 9996: Popular alternatives, especially with Cisco devices.
- 9025, 9026: Other recognized port options.
- 6343: The default for sFlow, often used alongside NetFlow.
- 4739: The default port for IPFIX (a NetFlow successor).
To run:
cargo run --example netflow_udp_listener_multi_threaded
cargo run --example netflow_udp_listener_single_threaded
cargo run --example netflow_udp_listener_tokio
cargo run --example netflow_pcap
cargo run --example manual_ipfix_creation
cargo run --example custom_enterprise_fields
The pcap example also shows how to cache flows that have not yet discovered a template. The custom_enterprise_fields example demonstrates how to register vendor-specific IPFIX fields.
Support My Work
If you find my work helpful, consider supporting me!