Making Sense of Network Telemetry: A Practical Guide for Operators

Most telemetry protocols are built to be efficient: they sample, summarise, or filter data before sending it. That makes them scalable — but also means you have to choose carefully what data to export and how fast.

The quality and speed of telemetry directly affect your visibility. If you’re relying on slow exports or shallow data, you may not detect threats or bottlenecks until it’s too late. That’s why understanding the differences between telemetry methods is so important.

Flow-Based vs Packet-Based Telemetry

A core concept in telemetry design is whether the data you collect is flow-based or packet-based.

Flow-based telemetry — such as NetFlow or IPFIX — summarises a conversation between two endpoints. It typically includes the source and destination IPs, ports, protocols, and byte/packet counts. This metadata is easy to store and analyse, but doesn’t include any payload or full packet details. Flow telemetry is ideal for traffic analysis and long-term metrics.

Packet-based telemetry — such as sFlow or PSAMP — captures real packet headers (and sometimes payloads) directly from the network. These are sampled, not exported in full, but still offer much higher granularity and support for real-time use cases like DDoS detection or anomaly tracking.

Packet-based methods offer faster insights because they don’t rely on flow timeout mechanisms. But they also generate higher data volumes and require more capable collectors.

In modern networks, we’ve seen the best results from a hybrid approach: using flow-based telemetry for historical insights and packet-based telemetry for fast detection and incident response.

Now that we’ve covered the fundamentals of network telemetry — and the key differences between flow-based and packet-based approaches — let’s look at how the most widely used telemetry protocols compare in practice. We’ll walk through their strengths, limitations, and what kind of use cases they’re best suited for.

The Network Telemetry Landscape at a Glance

Modern carrier-grade routers support a variety of telemetry protocols, each with its own strengths, limitations, and ideal scenarios. At first glance, the options can seem complex — and picking the right one isn’t just a matter of reading a spec sheet. You also need to consider how the protocol behaves in real-world conditions, including export latency, data granularity, and even quirks in a specific vendor’s implementation.

In the table below, we’ve distilled the key characteristics of widely used protocols so you can quickly compare them side by side and understand where each one fits best.

With this high-level map in mind, the next sections will take a closer look at each protocol — how it works, where it shines, and the trade-offs to consider before deployment.

NetFlow v5

NetFlow v5 is one of the oldest telemetry protocols and is still in use today, especially in legacy networks. It exports flow records after a session ends or reaches a timeout threshold, typically around 30 to 60 seconds.

The protocol is extremely limited: it does not support IPv6, its field set is fixed, and there is no flexibility for adding extra metadata. In practice, its long export delay means it cannot support real-time use cases like DDoS detection.

It’s only recommended if your hardware supports nothing else. For modern networks, it’s generally not sufficient.

NetFlow v9 / IPFIX

NetFlow v9 and its successor IPFIX introduce flexible templates that allow routers to export a richer set of data, including IPv6 support. These protocols can be customised to include BGP next hop, AS numbers, MAC addresses, and more.

However, this flexibility comes at a cost. Templates are often inconsistent across vendors and require careful parsing and version handling. Export delays still exist, as these protocols are still flow-based and depend on active/inactive timeouts.

Despite the complexity, NetFlow v9/IPFIX is widely supported and suitable for historical analysis or capacity planning, especially when paired with open-source or commercial collectors that support dynamic templates.

sFlow v5

sFlow is a packet-based telemetry protocol that exports raw packet headers and interface counters. Unlike NetFlow, it does not summarize flows. Instead, it samples packets at a configurable rate (e.g., 1 out of every 1,000) and exports them in real time.

Because of its low latency and rich data, sFlow can be used for security monitoring, real-time visibility, and traffic classification. However, not all hardware implements sFlow equally well. Some platforms only offer basic counters or limited metadata, and sample rates may be too low to detect short-lived traffic bursts.

When implemented properly, sFlow is lightweight and highly effective — but it’s worth verifying the capabilities of your specific router platform.

Port Mirroring

Port mirroring duplicates all traffic on a router or switch port and sends it to a collector or monitoring interface. It provides complete visibility into the packet stream — including payloads — and is often used for debugging or full packet capture.

However, port mirroring is resource-heavy. It consumes additional bandwidth, requires dedicated collectors, and doesn’t scale well in high-throughput environments. This makes it unsuitable as a general-purpose telemetry solution, except in narrow troubleshooting scenarios.

Sampled Port Mirror / PSAMP

A modern and efficient option for packet-based telemetry is sampled port mirroring, often using PSAMP (Packet Sampling) extensions. This method combines the speed and low latency of packet sampling with the metadata structure of IPFIX.

It allows you to define sampling rates, export formats, and filters, giving you precise control over the telemetry you generate. Exported data includes packet headers and, optionally, interface counters or BGP metadata.

In our experience, this is one of the best-performing telemetry methods available today — but only if your hardware supports it. Vendors like Juniper and Nokia offer robust PSAMP implementations, while others may still be catching up.

Why Speed Matters

Telemetry isn’t just about knowing what happened in your network — it’s about knowing it fast enough to respond. This is especially critical for DDoS detection and mitigation, where seconds matter.

Traditional flow-based telemetry (like NetFlow v5 or v9) introduces detection delays of 30 seconds or more. By the time you detect an anomaly, the attack may have already disrupted services. In contrast, packet-based telemetry methods such as sFlow or PSAMP can detect unusual traffic patterns in under 2 seconds.

At FastNetMon, our open-source detection engine supports all major telemetry protocols. In real-world tests, we’ve consistently seen the best performance with PSAMP and high-quality sFlow implementations. These methods provide fast, detailed visibility — enabling automated responses before damage occurs.

Choosing the Right Telemetry for Your Network

Each network is different, and no telemetry protocol is perfect. The right choice depends on several factors:

• What telemetry protocols do your routers and switches support
• How quickly do you need to detect traffic anomalies
• Whether you prioritise historical analytics or real-time visibility
• Your collector architecture and storage capacity

In modern environments, we recommend starting with packet-based telemetry if low-latency detection is a priority. Flow-based telemetry still has its place — especially when used in combination — but the industry is clearly moving toward faster, richer, and more flexible telemetry.

If you haven’t reviewed your telemetry setup in a while, now’s a good time.