Sun, sea, and… networking.
On September 11, Hari and Stephan will be at the beach in Scheveningen, for the annual NL-ix Late Summer Drink. Always a great chance to catch up with peers, exchange ideas, and enjoy the unique mix of seaside vibes and serious conversations about networks.
If you’re around, come say hi and join us for a beer. We’d love to chat about traffic visibility, peering, and what’s next for network analytics.
In theory, flow data should give us a nice, accurate view of what’s happening in our network. In reality, there’s a big elephant in the room: you never really know if the data you’re getting is complete. Flow exports are typically sent using UDP, and that means there are no guarantees. If a packet doesn’t make it to your collector – too bad, it’s gone.
For people who depend on flow data for analytics, capacity planning, security, and troubleshooting, that’s not just annoying; it’s dangerous. And most of the time, neither the user nor the collector has a way to detect if something’s missing.
We often hear: “Well, if my collector drops packets, I’ll know about it.” True – most collectors can log packet loss. And while the network in between could theoretically drop packets, in our experience, that’s rarely the bottleneck.
The real troublemaker? The exporter. That’s the router or switch generating the flows in the first place.
If the exporter silently drops flow data due to an internal issue, like a full buffer, nobody notices. Not the user. Not the collector. You just end up working with incomplete data, drawing the wrong conclusions, and maybe even alarming or scaling unnecessarily. The worst part? This often happens gradually as traffic grows, long after the initial configuration was done.
There are specific configuration parameters you can tweak to make flow exports more reliable and insightful. Here’s what matters most:
This defines how many packets the router skips before recording one. A lower number means better accuracy.
This defines how long the exporter waits without seeing new packets for a flow before it sends it out. We recommend 15 seconds. It keeps the buffers clean and prevents long-hanging flows from clogging up the memory.
This is the maximum duration a flow is kept “open” before being sent, even if new packets keep arriving.
If your analytics work in 5-minute buckets, this is crucial. If you use the vendor default (often 1800 seconds or more!), flows will straddle multiple buckets and make your data messy. We recommend 60 seconds to ensure clean aggregation.
Most major vendors give you tools to see if you’re dropping flow records at the source:
Check these regularly, especially if traffic volume has changed recently.
| Parameter | Recommended value | Why it matters |
| Sampling rate | 1:1000 | Balanced accuracy and router performance |
| Inactive timeout | 15 seconds | Flush idle flows quickly to free buffer |
| Active timeout | 60 seconds | Clean 5-minute time buckets, avoid overflow |
Each vendor has their own flavor of config:
Always validate configs against your version’s documentation.
If you’re sampling on both ingress and egress interfaces, you’re doing double the work (and seeing double the data!). We recommend ingress-only. It’s the earliest point you can capture a flow, and it prevents duplication.
Default configurations are not your friend. They are built for generic scenarios and not optimized for the accurate, actionable analytics we all depend on.
Take the time to check, tweak, and validate your exporter configuration. The benefits will ripple through the whole system: from better performance monitoring to more accurate security insights.
When monitoring your network traffic, you rely on tools to provide precise, actionable data. But what if some tools “lie” – not out of malice, but due to hidden methodologies that mask the truth? Let’s uncover how certain practices can lead to inaccurate traffic analyses.
A common discrepancy arises from how monitoring tools handle data over extended time periods. In order to be analysed, data first needs to be divided into buckets: the volume of traffic flowing through a network, measured in bytes, is collected in groups in order to process it. A bucket size is determined by time, so the size of the bucket is the amount of time in which the traffic data was collected, e.g. 5 minutes, 60 minutes, 24 hours, etc. Generally speaking, the smaller the bucket size, the more accurate the data analysis possible, for reasons which will follow.
Many tools use larger bucket sizes for long-term queries, which aggregate data into broader averages. For example, data might be processed on a daily basis (24 hours). While this might simplify storage and traffic visualization, it often leads to inaccurate, lower traffic values, masking critical peaks and underestimating actual usage. In other words, traffic peaks that would otherwise have been visible are averaged out, leading to smaller average values.
This perceived accuracy can result in:
At BENOCS, we’ve designed our system to ensure you always have a clear and accurate picture of your network traffic. Here’s how we address these issues:
We want to bring network analytics to everybody – from network engineers to marketing teams. For this reason, we identified the most expected behavior of these graphs as crucial default behavior. At the same time, we ensure transparency by displaying how these values are derived, leaving no room for guesswork, and enable our users to make adjustments to these default settings if necessary. This ensures that BENOCS users:
By combining intuitive defaults, transparency, and flexibility, BENOCS delivers the tools you need for accurate and actionable insights into your network.
Interested in a demo? Let us know!
