How a European network operator mitigated a 159 Gbps DDoS attack in under 10 seconds

The Operator

The operator runs IP transit and managed hosting services across multiple data centre locations in the EU, serving a customer base that includes enterprise, government, and mid-market accounts. Their backbone carries multi-100G capacity across several transit providers, and they sell dedicated server, colocation, and managed firewall services to downstream customers who rely on contractual uptime SLAs.

As a transit provider, the operator's exposure to DDoS is structural: they carry traffic for customers who are themselves targets. An attack against any downstream prefix has the potential to saturate shared uplinks and cause collateral impact on unrelated customers sharing the same transit path. The operator's NOC team handles dozens of DDoS incidents per month, but their existing tooling relied on SNMP-based threshold alerts with 60-second polling intervals and manual FlowSpec rule construction.

The Challenge

Before deploying Flowtriq, the operator's DDoS response workflow ran on a 60-second SNMP polling cycle. An anomaly had to persist for at least two polling intervals to confirm it was not a transient burst, meaning the earliest possible detection was 90 to 120 seconds after attack traffic began arriving. Once detected, the NOC engineer on duty would manually classify the attack vector, construct a FlowSpec rule in their router CLI, and push it to the transit provider's edge. The full cycle from first anomalous packet to upstream mitigation typically took 4 to 8 minutes.

For attacks under 20 Gbps, this workflow was tolerable. Most of their transit links could absorb that volume without saturating, and customer impact was limited to elevated latency during the response window. But larger attacks, particularly those exceeding 100 Gbps, would saturate transit links within seconds. By the time the SNMP alert fired, the damage was already in progress: packet loss across every customer sharing the affected uplink, support tickets from customers who had no idea they were not the target, and SLA clock running against the operator.

"At 20 gig, we have time to respond. At 100-plus, the link is saturated before our monitoring even registers the spike. We needed detection that could keep up with the attack ramp, not detection that catches it after the fact."

Head of Network Operations

Flowtriq was deployed across 12 nodes spanning the operator's core and edge infrastructure over a two-day rollout. Each ftagent baselined its node's traffic profile within five minutes. BGP FlowSpec adapters were configured against the operator's existing transit provider sessions, and cloud scrubbing integrations were connected and tested against a controlled 5 Gbps synthetic load before going live.

The Incident: May 2026

The attack arrived on a weekday morning during peak business hours. The target was a /24 prefix belonging to one of the operator's managed hosting customers, a public-sector organisation running citizen-facing web services. The prefix shared a 100G transit uplink with approximately 40 other customer prefixes.

At 10:14:38 CET, inbound traffic to the target prefix jumped from a 2.1 Gbps baseline to over 80 Gbps in the first three seconds.

What Happened: Minute by Minute

From the perspective of every downstream customer, including the target, nothing happened. The public-sector web services stayed online. The 40-plus other customers sharing the same transit uplink experienced no packet loss, no latency increase, and no indication that an attack had occurred. The only evidence was the incident record in the Flowtriq dashboard and the alert thread in the NOC's monitoring channel.

Attack Technical Breakdown

Post-incident analysis confirmed a coordinated multi-vector attack combining volumetric amplification with a state-exhaustion component, a common pattern designed to overwhelm both bandwidth and connection-tracking infrastructure simultaneously.

Why no customer was affected

Three factors kept the operator's entire customer base clean throughout the attack.

Detection during the ramp phase. The 0.7-second detection window caught the attack while it was still building. DNS amplification attacks reach peak volume over 5 to 15 seconds as reflected responses return from open resolvers worldwide. Flowtriq identified the anomaly at 47 Gbps, well before the attack reached its 159 Gbps peak. The FlowSpec rules were propagated to the transit provider's edge while the attack was still ramping, preventing the full 159 Gbps from ever reaching the operator's 100G uplink.

On-node mitigation as immediate protection. The automatic kernel-level rules pushed at T+5s protected all forwarding and application processes on the edge nodes while the upstream FlowSpec rules were being propagated. Legitimate customer traffic, which did not match the attack signatures, continued to be forwarded normally. The on-node rules served as a bridge: they bought the 4 seconds needed for FlowSpec propagation without any customer experiencing degradation.

Upstream mitigation at two layers. On-node rules protect the operator's infrastructure, but they do not recover saturated transit bandwidth. Flowtriq moved the drop point upstream in two ways simultaneously: FlowSpec rules at the transit provider's edge discarded matching packets before they consumed uplink capacity, and cloud scrubbing filtered volumetric traffic at an additional upstream layer. The combination meant attack packets were being dropped before they could reach the operator's network at all.

Where the attack traffic was stopped

Outcomes

What Changed After the Incident

Following this incident, the operator retired their SNMP-based DDoS detection entirely and moved to Flowtriq as their primary detection and mitigation platform across all edge and core nodes. Their NOC runbook for DDoS incidents was reduced from a 14-step manual procedure to a single step: verify the Flowtriq incident view and confirm upstream mitigation is active.

In the weeks since the May incident, Flowtriq has automatically mitigated seven additional attacks against various customer prefixes, ranging from 3 Gbps probes to a 68 Gbps DNS amplification hit. None required manual intervention. The NOC team reviews each incident post-facto via the dashboard but has not needed to manually construct a FlowSpec rule since deploying Flowtriq.

"We used to staff the NOC based on how fast someone could write a FlowSpec rule under pressure. Now the detection-to-mitigation path is faster than a human can open a terminal. The NOC still reviews every incident, but the response is already done by the time they look at it."

Head of Network Operations

Flowtriq Features Used

• Per-second anomaly detection: ftagent on 12 nodes, monitoring BPS/PPS deviations against dynamic per-prefix baselines
• Multi-vector co-detection: DNS amplification and TCP ACK flood both flagged in a single incident within the same 0.7s detection cycle
• Webhook alerting: real-time incident notification to the NOC monitoring channel with classification, target prefix, and live dashboard link
• Auto-mitigation rules: pre-configured kernel-level rules pushed automatically on matching attack signatures
• BGP FlowSpec adapter: upstream rules pushed to transit provider edge routers via one-click interface
• Cloud scrubbing integration: upstream scrubbing activated alongside FlowSpec for layered mitigation
• PCAP capture: automatic packet capture triggered at detection, stored for forensics and compliance
• Live incident view: real-time traffic graphs, source IP map, and mitigation controls in the dashboard

Related Articles