Glossary

IPFIX

IP Flow Information Export

What is IPFIX

IPFIX (IP Flow Information Export) is a standard protocol for collecting and exporting network traffic information, built to provide a universal, scalable way to describe and transmit flow-level data about what's actually happening on a network. Rather than exporting every individual packet, IPFIX summarizes traffic into flows — grouping packets sharing common characteristics — and exports that summary to a collector for analysis.

With IPFIX, network administrators can gather detailed traffic information — source and destination IP address, port numbers, byte counts, connection duration, and more — for use across network monitoring, billing, traffic engineering, and security analysis. Because it's a standard rather than a proprietary format, IPFIX-exported data can be consumed by any compatible collector or analytics platform, regardless of which vendor's equipment generated it.

How IPFIX Works

An IPFIX deployment is built from three configured pieces that work together: an exporter, a monitor-map, and a monitor interface.

The exporter defines where flow data actually gets sent and how it's packaged. It's configured with a destination IP and port (where the collector is listening), a source IP and port (identifying the exporting device itself), a domain ID (distinguishing this exporter's data stream from others the same collector might receive), a path MTU (controlling how exported packets are sized), and a template-transmission interval (how often the exporter resends the template describing its data's structure, which collectors need in order to correctly parse incoming flow records).

The monitor-map defines what gets analyzed and exported, independent of any specific interface. It binds to one or more exporters, sets the record depth — whether flow analysis looks at Layer 2, Layer 3, Layer 4, or all of them — and sets two timers that control when a flow record actually gets exported: an active timeout, which caps how long a single ongoing flow can be tracked before it's exported anyway (so a long-lived connection doesn't just accumulate forever without ever being reported), and a passive timeout, which determines how long an idle flow is kept before being considered finished and exported.

Finally, the monitor interface is where a monitor-map actually gets applied to real traffic — bound to a specific interface, with a specified traffic type (IPv4, IPv6, or Layer 2) and direction (received, transmitted, or both). This is what turns the exporter and monitor-map configuration from a definition into something actively observing traffic and generating flow records.

Why IPFIX is Beneficial

  • Scales far better than full packet capture: Summarizing traffic into flow records instead of exporting every packet keeps IPFIX's overhead manageable even on high-throughput links, while still preserving the metadata that most monitoring and analysis use cases actually need.

  • Standardized, not proprietary: Because IPFIX is a defined standard rather than a vendor-specific flow format, exported data can be consumed by any compatible collector, avoiding lock-in to a single vendor's analytics stack.

  • Serves multiple operational needs from one data stream: The same flow export can feed network monitoring, capacity planning, usage-based billing, and security analysis simultaneously, rather than requiring separate instrumentation for each.

  • Timeout controls keep data timely, not just eventually accurate: Active timeouts ensure long-running flows get reported on a predictable cadence rather than staying invisible until they finally end, which matters for anything approaching real-time visibility.

  • Granular depth where it's needed: Choosing Layer 2, Layer 3, Layer 4, or full-depth analysis per monitor-map lets operators match collection detail to what a given use case actually requires, rather than paying the overhead of full analysis everywhere.

At Asteraix

What We Can Do at Asteraix

AsterNOS implements IPFIX as a fully CLI-configurable flow-export pipeline, alongside traditional port mirroring for direct traffic capture — giving operators both summarized flow data and raw packet-level visibility from the same platform.

  • Complete exporter configuration: ipfix exporter <name> creates an exporter, configured with dip/dport (destination), sip/sport (source), domain_id, path_mtu, template_interval, and an optional vrf for the exporter's egress path — giving operators full control over exactly how and where flow data leaves the device.

  • Flexible monitor-map definition: ipfix monitor-map <name> binds to one or more exporters and sets analysis depth with record {l2|l3|l4|all}, alongside independently configurable timeout_active and timeout_passive values — letting operators tune both what gets analyzed and how often it gets reported.

  • Per-interface, per-direction monitoring: ipfix monitor <name> {ip4|ip6|l2} {both|rx|tx}, applied inside interface configuration view, attaches a monitor-map to a specific interface with precise control over traffic type and direction — confirmed in AsterNOS's own documented example collecting all Layer 2 traffic, both directions, from a single interface.

  • Traditional port mirroring for raw packet capture: mirror session <id> span direction {both|inbound|outbound} dst-ethernet <port> src-ethernet <port> complements IPFIX's summarized flow export with full packet mirroring to a connected analysis device — useful when a specific troubleshooting scenario calls for actual packet contents rather than flow-level metadata.

  • Built-in visibility for verification: show ipfix exporter, show ipfix monitor, and show ipfix port-map, alongside show mirror session for port mirroring, let operators confirm both IPFIX and mirroring configuration directly from the CLI — including the exact tabular session output AsterNOS's documentation shows for a live mirror session.