[Case Study] kt cloud Internalizes Network Metering with IPFIX and Goflow2

With the ML2/OVN migration, OVN began handling routing via OVS Flow, rendering the existing Neutron-metering-agent's iptables counter method ineffective. Since packets no longer passed through the Linux IP stack, there was no place left to read the counters from.

As alternatives, sFlow and IPFIX were compared and reviewed. sFlow uses 1/N probabilistic sampling, which has low overhead but relies on statistical estimation, lacking billing accuracy. IPFIX, on the other hand, maintains Flow state based on 5-Tuple inside OVS, accumulating packet counts and byte counts before exporting them on Timeout, making it closer to actual measured values. IPFIX was ultimately adopted.

The biggest challenge was mapping IP → Project ID (Tenant ID). Calling the Neutron API for every record would immediately overload the control plane, so the Goflow2 source code was directly modified to embed an Enrichment module based on a local memory cache.

The pipeline operates in 3 stages:

• Initial Sync: At startup, IP ↔ Project ID mappings for FIP/NAT resources are loaded into memory as a Hash Map from OVSDB
• Watch & Update: Subscribes to change events via OVSDB Monitor RPC to update the Hash Map in real time
• Zero-Latency Enrichment: Upon receiving an IPFIX record, tags openstack_src_project_id using only an in-memory lookup with no external calls, then sends it to Kafka

The Sampling Rate was fixed at 1 (full collection) to prevent billing omissions, and OVS Flow Cache tuning (adjusting Active/Inactive Timeout) minimized performance overhead on compute nodes.