July 10, 2026
·
11 minutes read
DDoS detection speed decides whether customers notice. Port-mirror (DPDK) inspects 100% of packets for 2-5s reaction; NetFlow/sFlow/IPFIX is sampled and slower.
DDoS detection comes in two families: packet-based inspection via a port mirror (SPAN/TAP) with DPDK, which sees 100% of traffic at line rate and reacts in roughly 2-5 seconds, and flow-based analysis of sampled records (NetFlow, sFlow, IPFIX) exported by your routers, which is cheaper and covers many sites but reacts in roughly 35-95 seconds. The gap between them is speed, and on a modern uplink speed is what decides whether your customers ever notice the attack.
Key takeaways
- Two detection families: port-mirror packet inspection (DPDK) and flow-based analysis (NetFlow/sFlow/IPFIX).
- Port-mirror (DPDK) inspects every packet at line rate, so it detects in ~2-5 seconds and never misses a vector.
- Flow (NetFlow/sFlow/IPFIX) is sampled (e.g. 1-in-1000), bandwidth-independent and cheap, but reacts in ~35-95 seconds.
- Sampling has blind spots: low-rate and fragment-based floods can slip past statistical reconstruction.
- WanGuard runs both in one system: DPDK where speed matters most, flow everywhere else.
What is DDoS detection?
DDoS detection is the process of recognizing that a distributed denial-of-service attack is under way, by profiling live traffic and firing an alert the moment a subnet's rate, packet mix, or protocol distribution breaks its learned baseline. It answers one question fast: is this traffic normal, or is it an attack? Detection is separate from mitigation, the acting on that alert, but the two are chained: detection has to fire before any filter, BGP FlowSpec rule, or black-hole can drop a single packet.
The method you choose to feed the detector, mirrored packets or exported flows, sets both your reaction time and your cost. That single choice is the subject of this post.
Why does detection speed decide whether customers notice?
Detection speed matters because modern floods saturate uplinks in tens of seconds, not minutes. Cloudflare reported that DDoS attacks rose 121% year over year in 2025 and that it blocked a record 31.4 Tbps flood lasting just 35 seconds, with telecoms, service providers and carriers the most-targeted industry for hyper-volumetric attacks. (Cloudflare Q4 2025 DDoS Threat Report, Feb 2026.)
Read that number again: 35 seconds, start to finish. A detection method that reacts in 35-95 seconds can miss a short hit entirely, or catch it only after the uplink is already congested and customers are already timing out. NETSCOUT's parallel data recorded more than 8 million DDoS attacks in the second half of 2025 across 203 countries, with roughly 42% using two to five vectors at once. (NETSCOUT DDoS Threat Intelligence Report, Issue 16, Mar 2026.) Multi-vector, short-duration attacks are exactly the pattern that punishes slow, sampled detection.
The practical rule we work to: your time-to-detect has to be shorter than your time-to-saturate. On a busy 100GE edge, that budget is measured in seconds.
[CHART: Timeline bar – attack onset to uplink saturation (~35s) overlaid with port-mirror detection (~2-5s) vs flow detection (~35-95s) – source: Cloudflare Q4 2025 for the 35s reference, ITORO deployment figures for detection times]
How does port-mirror (DPDK) detection work?
Port-mirror detection inspects a full copy of your traffic. A switch or router SPAN/mirror session (or a passive optical TAP) duplicates every packet to a monitoring port, and a WanGuard Packet Sensor using DPDK (the Data Plane Development Kit) captures those packets in user space at line rate. Because it reads 100% of packets, nothing is estimated: every header, protocol, flag and fragment is seen directly.
DPDK is what makes this viable on high-speed links. It bypasses the Linux kernel network stack, using poll-mode drivers and hugepages to move packets with minimal per-packet overhead, so a commodity server can inspect tens or hundreds of Gbps. (DPDK project documentation, dpdk.org.) The payoff is reaction time: in ITORO deployments, port-mirror detection typically flags a volumetric flood in 2-5 seconds, fast enough to trigger sub-5-second RTBH or 15-30-second granular filtering.
The trade-off is coverage cost. You need mirror capacity and a sensor at each inspection point, so covering many geographically spread POPs with packet capture everywhere gets expensive. Port-mirror is the tool you place where speed matters most: your busiest edges and highest-value customers.
How do NetFlow, sFlow and IPFIX detection work?
Flow-based detection analyzes summary records your routers already export, so it needs no packet mirror and no extra tap. A WanGuard Flow Sensor collects these records, rebuilds a statistical picture of traffic per subnet, and raises an anomaly when the picture breaks baseline. Three export formats dominate, and they do not work the same way:
NetFlow and IPFIX (flow-cache export)
NetFlow (Cisco-origin, v5/v9) and its IETF standard successor IPFIX (RFC 7011) keep a flow cache: the router groups packets into flows and exports a record when the flow ends or a timer expires. The active flow timeout governs how quickly a long-running flood is reported, and its default is commonly around 60 seconds, though it is tunable lower on many platforms. (Cisco IOS NetFlow configuration guidance; RFC 7011.) That timer is the main reason flow detection often lands in the tens-of-seconds range.
sFlow (packet sampling)
sFlow takes a different path: it samples 1-in-N packets and streams those samples continuously as datagrams, with no flow cache to expire. (sFlow.org; RFC 3176 as the informational reference.) Because it does not wait for a flow to close, sFlow can react faster than classic NetFlow, but it is still sampled, so it trades completeness for real-time delivery.
All three share the same core economics. Flow export is bandwidth-independent (you send records, not a copy of the traffic), it covers every router that already speaks the protocol, and it scales to Terabit volumes cheaply. The cost is time and detail: because records are sampled (commonly 1-in-1000 or 1-in-2000 on high-speed links) and often aggregated over an export interval, flow detection in production typically lands around 35-95 seconds, and it sees a coarser picture than packet capture.
Port-mirror vs NetFlow/sFlow/IPFIX: the comparison
Here is the honest side-by-side. Neither method is "better" in isolation; each wins a different job, which is why most mature edges run both.
| Factor | Port-mirror (DPDK packet sensor) | NetFlow / IPFIX | sFlow |
|---|---|---|---|
| Data seen | 100% of packets | Sampled flow-cache records | Sampled packet headers |
| Sampling | None (full inspection) | Yes (plus cache aggregation) | Yes (1-in-N) |
| Typical detection speed | ~2-5 s | ~35-95 s (active-timeout bound) | Faster than NetFlow, still sampled |
| Coverage model | Per inspection point (tap/SPAN) | Every router that exports | Every router that exports |
| Bandwidth cost | Needs mirror/tap capacity | Bandwidth-independent | Bandwidth-independent |
| Relative cost | Higher per site | Low | Low |
| Blind spots | Effectively none | Low-rate, fragment, sub-sampling | Sampling gaps |
| Best for | Busy edges, high-value links | Wide multi-POP coverage | Real-time wide coverage |
[IMAGE: Network edge diagram showing a router SPAN/mirror feeding a DPDK packet sensor on one path and NetFlow/sFlow/IPFIX export feeding a flow sensor on another – search terms: network diagram router mirror port monitoring server]
The line-rate visibility that packet capture gives you pairs naturally with Juniper MX telemetry, so your NOC watches the same attack and the same mitigation on one live dashboard, whichever sensor raised the alarm.
Where does sampling create blind spots?
Sampling creates blind spots because a flow sensor reconstructs traffic statistically from a fraction of packets, so anything that hides in the gaps between samples is easy to under-count or misread. At 1-in-1000, a low-rate but damaging pattern, a slow application-layer flood, a targeted state-exhaustion attack, may simply not accumulate enough sampled packets to cross a threshold in time.
Fragment floods are the classic example. IP fragments after the first carry no Layer 4 header, so they hold no TCP/UDP port information, which means flow records can misclassify or mis-bucket them, and sampling degrades that picture further. (RFC 791 fragmentation behavior.) A DPDK packet sensor, by contrast, sees every fragment directly and can reassemble or count them precisely. The same logic applies to short bursts: a 35-second hit gives a 60-second active timeout no chance to export in time.
None of this makes flow detection useless. It means you place it where its blind spots do not matter and back it with packet capture where they do.
When should you use each method?
Use the method that matches the value and speed budget of each link, and in most real networks that means using both. There is no single winner: the choice is an engineering trade between reaction time and the cost of covering every site with full packet inspection.
- Use port-mirror (DPDK) on your busiest edges, your peering and transit uplinks, and your highest-value customer segments, anywhere a few seconds decide whether the pipe saturates before you react.
- Use flow (NetFlow/sFlow/IPFIX) for broad, economical coverage across many POPs and internal routers, where deploying a tap everywhere is impractical and a slightly slower alarm is acceptable.
- Run both together, which is the norm on mature networks: packet capture for speed where it counts, flow for reach everywhere else, with one console correlating the two.
This is precisely how ITORO scopes DDoS protection services: map each link to a detection method by its risk, not a one-size rollout.
How WanGuard supports both detection methods
WanGuard is built around exactly this dual model, which is why we standardize on it. Its Packet Sensor captures mirrored traffic over DPDK for sub-5-second, full-visibility detection, and its Flow Sensor ingests NetFlow (v5/v9), sFlow (v5) and IPFIX for bandwidth-independent coverage at Terabit scale. (Andrisoft WanGuard documentation.) Both feed the same detection engine and the same console, so an alert from either triggers the same automated response.
That means you do not pick a camp and live with its blind spots. You deploy DPDK port-mirror on the links where 2-5-second reaction is non-negotiable, deploy flow sensors across the wider edge for reach, and let one system correlate them, detect the attack, and hand off to mitigation (FlowSpec first, RTBH as a last resort). Detection accuracy still depends on tuning: per-subnet baselines, exclusions for known heavy customers, and clean thresholds. Get that right and both methods produce accurate, automatic alarms; get it wrong and either one produces false positives.
ITORO is a worldwide Andrisoft Gold Partner with 25+ years of ISP and network operations (20+ years with Juniper). We install, tune and operate both detection modes as a managed service, end to end, at the same price worldwide.
Frequently asked questions
What is the fastest DDoS detection method?
Port-mirror detection with DPDK is the fastest, typically reacting in about 2-5 seconds. It inspects 100% of packets at line rate through a SPAN/mirror or optical tap, so nothing is sampled or estimated. Flow-based detection (NetFlow/sFlow/IPFIX) is cheaper and covers more routers, but usually reacts in roughly 35-95 seconds.
What is the difference between port-mirror and NetFlow DDoS detection?
Port-mirror detection inspects a full copy of every packet via DPDK, so it sees all traffic at line rate and detects in seconds. NetFlow detection analyzes sampled summary records your routers export from a flow cache, which is bandwidth-independent and cheap but slower (bounded by the active flow timeout, often around 60 seconds) and coarser.
Is sFlow faster than NetFlow for detecting DDoS?
It can be. sFlow streams sampled packet headers continuously with no flow cache to expire, so it does not wait for a flow-timeout the way classic NetFlow and IPFIX do. Both are still sampled, so both remain slower and coarser than full DPDK packet inspection, and both share sampling blind spots on low-rate and fragment floods.
Why does DDoS detection speed matter so much?
Because modern floods saturate uplinks in tens of seconds. Cloudflare recorded a record 31.4 Tbps attack that lasted just 35 seconds (Cloudflare, Feb 2026). If your detection reacts in 35-95 seconds, a short hit can end, or your uplink can congest, before mitigation ever starts. Detection must be faster than uplink saturation.
Can flow-based detection miss attacks that port-mirror catches?
Yes. Because flow data is sampled (commonly 1-in-1000), low-rate and short-burst attacks can slip past statistical thresholds, and fragment floods are hard to classify because non-first fragments carry no Layer 4 port information. A DPDK packet sensor sees every packet and fragment directly, which is why speed-critical links pair flow coverage with full packet inspection.
Sources
- Cloudflare — Q4 2025 DDoS Threat Report (Feb 2026): https://blog.cloudflare.com/ddos-threat-report-2025-q4/
- NETSCOUT — DDoS Threat Intelligence Report, Issue 16 / 2H 2025 (Mar 2026): https://www.netscout.com/threatreport/
- IETF — RFC 7011, Specification of the IP Flow Information Export (IPFIX) Protocol: https://www.rfc-editor.org/rfc/rfc7011
- IETF — RFC 3176, InMon Corporation's sFlow: https://www.rfc-editor.org/rfc/rfc3176
- IETF — RFC 791, Internet Protocol (IP fragmentation): https://www.rfc-editor.org/rfc/rfc791
- DPDK — Data Plane Development Kit documentation: https://doc.dpdk.org/guides/
- Andrisoft — WanGuard product & documentation: https://www.andrisoft.com/software/wanguard
