Move Beyond Raw Flow Data
The operational value of flow data comes from understanding what it means during an incident, not simply collecting it.
IP Flow Information Export (IPFIX) is the IETF standard for exporting information about traffic flows from network devices. Routers, switches, firewalls and dedicated probes observe packets as they pass through, group them into flows that share common properties such as source and destination address, ports, protocol and interfaces, and periodically export a record that summarises each flow. A typical record describes who was talking to whom, over which interfaces, for how long and how many packets and bytes were exchanged. IPFIX grew out of NetFlow version 9 and uses templates, so exporters can describe exactly which fields they send, including details such as BGP next hop, source and destination autonomous system numbers or application identifiers.
Collecting this data is rarely the hard part. Most modern network equipment can export flow records, and a busy network can generate millions of them every minute. The difficulty is that a raw flow record answers a very narrow question: a particular conversation happened at a particular time. On its own, a single record does not say whether that traffic was normal, whether it moved, whether it grew, or whether it had anything to do with a problem users are reporting.
During an incident, network teams are not looking for individual conversations. They are trying to answer broader questions. Did traffic to a particular service drop? Did it start leaving the network through a different exit point? Did a link suddenly carry far more than it usually does? Did a set of destinations become unreachable, or did traffic towards them simply take a longer path? These are questions about change and context, and they can only be answered when flow data is aggregated, compared over time and placed alongside other operational information.
There are also practical limits to keep in mind. Flow data is frequently sampled, so a device may only inspect one packet in every few hundred or few thousand. Sampling is reliable for showing trends and large traffic volumes, but it can understate small flows and short bursts. Records are exported when a flow ends or when an active timeout expires, which means there is always some delay between traffic being observed and records arriving at a collector. Exporters, templates and sampling rates can differ from one device to another. Interpreting flow data well means understanding these characteristics, so that a change in the numbers reflects a change in the network rather than a change in how the data was collected.
The shift that makes flow data operationally useful is moving from storing records to asking questions of them: what normally happens, what is happening now, and what changed in between. When IPFIX data is analysed with that focus, it becomes a record of how traffic actually behaved during an incident, which is often the most direct evidence of user impact a network team has.
Traffic Evidence to Review
IPFIX analytics can help teams focus on meaningful traffic changes.
Not every traffic change matters. Volumes rise and fall through the day, new services appear, and users shift between applications constantly. The useful question during an investigation is which changes are unusual, which coincide with the problem being investigated and which are large enough to affect users. Reviewing the following types of traffic evidence together helps teams separate meaningful changes from normal variation.
- Traffic distribution
- Traffic shifts
- Utilization changes
- Destination behaviour
- Traffic patterns during incidents
Traffic distribution
Traffic distribution describes how traffic is spread across the network: which interfaces, links, peers, transit providers and exit points carry it, and in what proportions. Most networks have a recognisable distribution under normal conditions. A certain share of traffic leaves through each upstream, a certain share arrives from each peer, and particular sites or links carry a predictable portion of the load. Knowing this baseline matters because many problems first appear as a change in proportions rather than in total volume. Total traffic may look unchanged while the share carried by one provider falls sharply and the share carried by another rises, which can indicate that a route was withdrawn, a preference changed or a session went down.
Traffic shifts
A traffic shift occurs when traffic that normally follows one path starts following another. Shifts can be planned, such as during maintenance or after a deliberate change to routing policy, or unplanned, such as after a link failure, a session reset or an unexpected route change elsewhere on the internet. Reviewing which traffic moved, where it moved from and to, and exactly when the movement started helps teams understand the scope of a change. A shift that affects only traffic to a handful of prefixes suggests a specific routing change, while a shift that moves most traffic from one exit point to another points to something broader, such as a failed upstream or a change in local preference.
Utilization changes
Utilization describes how heavily links and interfaces are being used relative to their capacity. Flow data shows not only that a link is busier than usual but also what kind of traffic made it busier, which matters when deciding how to respond. A sudden rise in utilization on a backup link may be the expected result of traffic failing over, while a rise on a link that should be unaffected may mean traffic has been drawn onto a path that was never meant to carry it. Sustained high utilization can lead to congestion, queuing and packet loss, so utilization changes are often the point where a routing change becomes visible to users as degraded performance.
Destination behaviour
Destination behaviour looks at traffic from the point of view of where it is going: specific prefixes, autonomous systems, services or regions. Reviewing traffic by destination shows whether a change affects everything or only particular targets. If traffic towards a set of destinations drops to nearly zero while traffic to everything else continues normally, those destinations may have become unreachable or may be receiving traffic through a path the team is not observing. If traffic to a destination continues but its volume or exit point changes, the destination is still reachable but the route towards it has moved. Grouping destinations by origin network or by the path used to reach them can quickly connect a traffic change to a specific routing event.
Traffic patterns during incidents
Incidents tend to leave recognisable marks in traffic data. A sharp drop can indicate lost reachability, a sudden spike can indicate a failover, a retransmission storm or unexpected or unwanted traffic, and repeated oscillation can indicate that traffic is following an unstable route back and forth. Comparing traffic during the incident window with the same period on previous days or weeks helps teams tell whether a pattern is genuinely unusual or part of normal cycles. Looking at the moments just before and just after an incident is equally important, because the order in which changes appeared often points to the cause, and the way traffic returns to normal shows whether the problem has actually been resolved.
Add Traffic Context to Investigation
Traffic intelligence helps teams understand whether traffic behaviour changed after a routing event or during changing network conditions.
Routing data and traffic data answer different questions. Routing data shows what paths were available and which were selected: which prefixes were announced or withdrawn, how AS paths changed and which peers were involved. Traffic data shows what actually happened to packets as a result. A routing change that affects a prefix nobody sends traffic to may have little operational impact, while a small change to a prefix that carries a large share of traffic can affect many users. Bringing the two together lets teams understand not only that something changed but also whether it mattered.
Align traffic changes with routing events
The most useful step in many investigations is placing traffic changes and routing events on the same timeline. If traffic to a group of destinations shifted to a different upstream within moments of a withdrawal or path change, the routing event is a strong candidate for the cause. If traffic shifted well before any routing change was observed, or if no routing change coincides with the shift at all, the cause is more likely to be elsewhere, such as in a physical link, a device, a configuration change or the destination itself. Precise timestamps matter here, so it is worth accounting for flow export delays and keeping clocks synchronised across devices.
Assess the impact of routing changes
Not every route change needs urgent attention. Traffic context helps teams decide which ones do. By looking at how much traffic was associated with the affected prefixes, how many destinations or customers were involved and whether traffic was lost, rerouted or simply rebalanced, teams can estimate the real impact of a routing event. This makes it easier to prioritise work, communicate accurately with stakeholders and avoid spending time on changes that had no measurable effect on traffic.
Understand behaviour under changing network conditions
Networks change constantly through maintenance, capacity upgrades, new peering arrangements and policy adjustments. Traffic data shows how the network actually responded to each change. Teams can confirm that traffic moved as intended after a planned change, spot traffic that ended up somewhere unexpected and see whether alternative paths had enough capacity to absorb the load. Over time, this builds a clearer picture of how traffic behaves when conditions change, which improves planning for future changes and failures.
When traffic evidence is reviewed alongside routing context, teams can:
- Identify which traffic changed and when the change began
- Determine whether traffic moved after a routing event or for another reason
- See which links, providers and destinations were affected
- Estimate the impact of a change by the volume of traffic involved
- Build an incident timeline that combines routing and traffic evidence
Flow data is one of the clearest records of how a network is actually being used, but its value depends on how it is interpreted. Collected and left unexamined, IPFIX records are simply a large archive of past conversations. Analysed for distribution, shifts, utilization, destination behaviour and incident patterns, and placed alongside routing events, they show what changed, when it changed and who was affected. That traffic context helps network teams move from noticing that something is wrong to explaining what happened and why, based on what the data shows rather than on assumptions.