BGP mitigation and DDoS automation:
how Flowtriq orchestrates multi-layer defense

Detecting a DDoS attack is only half the problem. The other half is doing something about it before your users notice. Most teams have some form of detection in place, but the gap between "attack detected" and "attack mitigated" is where downtime lives. That gap exists because detection systems and mitigation systems are usually completely separate, operated by different teams, configured in different consoles, and connected by nothing more than a human reading an alert and typing commands.

Flowtriq closes that gap. Our mitigation engine ties detection directly to action. When an attack crosses a threshold, mitigation rules deploy automatically, within the same second, across whatever layer makes sense: local firewall, BGP FlowSpec, RTBH blackhole, or cloud scrubbing diversion. No human in the loop, no SSH sessions at 3am, no copy-pasting community strings into a router CLI.

This post is a technical deep dive into how the entire system works: native flow ingestion for upstream visibility, the BGP adapters, the escalation logic, the safety mechanisms that prevent collateral damage, and the 46 local mitigation rule types that execute directly on your nodes.

Native Flow Collection: sFlow, NetFlow, and IPFIX

Before diving into the mitigation engine, there is a significant detection story to tell. Flowtriq now natively ingests flow telemetry from your routers, switches, and network infrastructure. No third-party collectors, no extra software. The ftagent handles it directly.

Previously, DDoS detection relied solely on per-server packet inspection via the ftagent reading /proc/net/dev. That works well for server-level visibility, but it means you only see an attack after it arrives at the node. Flow protocols change this by giving you upstream visibility: you see attack traffic at the router level before it reaches the server. This means faster detection, richer source IP intelligence from the first second of an attack, and support for environments where packet capture is not feasible: cloud VPCs, managed infrastructure, and high-throughput 100G+ links.

Four protocols are supported with auto-detection:

Protocol	Standard	Default Port	Format
sFlow v5	RFC 3176	6343	Sampled packet headers with interface counters
NetFlow v5	Cisco proprietary	2055	Fixed-format 48-byte flow records
NetFlow v9	RFC 3954	2055	Template-based with automatic template caching
IPFIX	RFC 7011	4739	Template-based (NetFlow v10) with enterprise fields

Here is how the ingestion pipeline works:

1. The ftagent starts a UDP listener on a configurable port (per protocol defaults above)
2. Binary protocol parsers decode incoming datagrams: sFlow v5 sampled packet headers, NetFlow v5 fixed-format records, and NetFlow v9/IPFIX template-based records with automatic template caching
3. Flow records are normalized and aggregated into 1-second PPS/BPS windows
4. The agent's detection loop merges flow data with local /proc/net/dev metrics, using the higher reading for threshold comparison
5. During attacks, flow-sourced top source IPs and destination ports are included in the initial incident report for immediate visibility

Everything is configurable per-node from the dashboard: protocol, port, sample rate, and allowed source IPs. Built-in router configuration snippets are included for Juniper, Cisco IOS/IOS-XE, and MikroTik so you can point your infrastructure at Flowtriq in minutes.

BGP Adapter Integrations

Flowtriq does not run its own BGP daemon. Instead, it speaks to whatever BGP speaker you already have in your network through adapter integrations. Each adapter translates Flowtriq's mitigation intent (rate-limit this prefix, blackhole that source, divert traffic to scrubbing) into the exact API calls or commands that your specific BGP implementation expects.

Eight adapters are currently supported:

Adapter	Protocol	Use Case
ExaBGP	JSON/HTTP API	The most popular open-source BGP speaker for automation. Flowtriq pushes routes via its HTTP API
GoBGP	gRPC REST API	High-performance Go-based BGP daemon. Supports SAFI 133 FlowSpec natively
BIRD 2	birdc socket proxy	Dominant among European ISPs. Flowtriq generates native BIRD flow specification syntax
FRRouting (FRR)	vtysh command proxy	Standard on whitebox switches and SONiC. Uses PBR-based filtering for mitigation
Cloudflare Magic Transit	Cloudflare API v4	Direct prefix advertisement and withdrawal for cloud scrubbing
Radware DefenseFlow	REST API	Enterprise scrubbing appliance integration. Creates and manages protection policies
F5 DDoS	iControl REST	Enterprise appliance. Manages DoS profile activation and deactivation
Generic Webhook	Signed HTTP POST	Integrate with anything: Path.net, Voxility, custom in-house systems

Every adapter is health-checked automatically every 5 minutes. Flowtriq tracks latency and marks adapters as healthy, degraded, or down. If the primary adapter goes offline, the engine automatically fails over to a healthy backup. Session drops trigger alerts via Slack and Telegram so your NOC knows immediately.

BGP FlowSpec (RFC 5575)

FlowSpec is BGP's built-in mechanism for distributing traffic filtering rules across a network. Instead of blackholing an entire prefix (killing good traffic along with bad), FlowSpec lets you write surgical rules that match specific traffic patterns and apply targeted actions.

Flowtriq supports FlowSpec for both IPv4 (AFI 1, SAFI 133) and IPv6 (AFI 2, SAFI 133). The match fields cover everything you need to describe an attack:

• Destination prefix and source prefix for targeting specific flows
• IP protocol (TCP, UDP, ICMP, ICMPv6 = protocol 58)
• Destination port and source port for service-specific filtering
• Packet length for catching amplification attacks (which tend to have uniform packet sizes)
• TCP flags for SYN flood mitigation
• DSCP for QoS-based filtering

Three action types are supported:

• Discard: drop matched traffic entirely
• Rate-limit: throttle to a specified bits-per-second threshold
• Redirect to VRF: divert matched traffic to a scrubbing center VRF using route target (RFC 5575 extended community type 0x8008)

When Flowtriq detects an attack, it automatically maps the attack classification to the right FlowSpec rule. Twelve attack types have pre-built mappings: SYN flood, UDP flood, DNS flood, NTP flood, SSDP flood, memcached flood, ICMP flood, HTTP flood, multi-vector, and several others. Unknown attack types get a conservative rate-limit rule rather than a hard drop, minimizing the risk of blocking legitimate traffic.

RTBH Blackhole

When FlowSpec is not enough, or when your upstream peers do not support it, RTBH (Remotely Triggered Black Hole) routing is the next escalation. RTBH works by announcing a /32 or /128 route with a specific BGP community that tells upstream routers to drop all traffic destined for that IP.

Flowtriq supports several community mechanisms:

• Standard community: 65535:666 (RFC 7999 BLACKHOLE), the universally recognized blackhole signal
• Large Communities: RFC 8092 format (ASN:function:parameter) for granular upstream signaling
• Selective per-peer blackholing: different communities per upstream peer, so you can blackhole traffic from Transit A but not from your IX peer B

The blackhole next-hop is configurable (default 192.0.2.1, TEST-NET-1 per RFC 5737). All announcements go through RPKI validation first: Flowtriq checks the prefix against the Cloudflare RPKI API (with a 1-hour cache) and warns if the prefix is RPKI-invalid, preventing upstream rejection of your announcement.

Blackhole rules also have persistency built in. If the BGP daemon restarts, Flowtriq automatically re-announces all active blackhole rules so protection is not interrupted.

4-Level Auto-Escalation

Not every attack needs a blackhole. A 200 Mbps UDP flood should be rate-limited, not dropped entirely. A 10 Gbps volumetric attack probably needs cloud scrubbing. The question is: how do you make the right call automatically?

Flowtriq uses a 4-level escalation model with configurable thresholds at each level:

Level	Default Threshold	Action
1. Local	>100 Mbps	FlowSpec rate-limiting. Throttle the attack traffic to a sustainable level
2. FlowSpec	>500 Mbps	Protocol and port-specific drop rules. More aggressive filtering
3. RTBH	>2 Gbps	Full /32 or /128 blackhole with community tagging
4. Scrubbing	>5 Gbps	Cloud scrubbing diversion via Cloudflare, OVH, Hetzner, Radware, or F5

Escalation happens automatically. If an attack starts at 300 Mbps, Flowtriq deploys level 1 rate-limiting. If the attack intensifies to 600 Mbps, it escalates to level 2 FlowSpec drops. If it ramps to 3 Gbps, RTBH kicks in. All of this happens without human intervention.

Every threshold, TTL, and cooldown timer is configurable per tenant. You can also enable or disable auto-escalation entirely if you prefer manual control at certain levels.

Cloud Scrubbing Automation

Level 4 escalation diverts traffic to a cloud scrubbing provider. Flowtriq integrates with the major scrubbing services and automates the entire diversion workflow: detect attack, announce prefix to scrubber, wait for traffic to reroute, and automatically withdraw the announcement when the attack resolves.

Provider	Method	Auto Trigger
Cloudflare Magic Transit	Direct API (prefix advertise/withdraw)	Yes
OVH VAC	OVH API (permanent mitigation toggle)	Yes
Hetzner	Robot API (hardware firewall toggle)	Yes
Radware DefenseFlow	REST API (protection policies)	Yes
F5 DDoS	iControl REST (DoS profiles)	Yes
Path.net	Webhook adapter	Yes
Voxility	Webhook adapter	Yes
AWS Shield	SigV4 API (subscription health)	Monitor
Generic	Signed webhook	Yes

The key advantage is cost. Most scrubbing providers charge by always-on bandwidth or by diversion duration. With automated diversion, you only route through scrubbing during active attacks. Peacetime traffic goes direct, costing nothing. Flowtriq handles the announcement, monitors the attack, and withdraws the prefix as soon as the incident resolves.

46 Local Node Mitigation Rule Types

BGP mitigation handles network-layer defense. But many attacks, especially L7, need to be stopped at the node itself. Flowtriq deploys firewall and filtering rules directly on your servers through the agent, giving you 46 distinct action types across 11 tool groups:

• iptables (7 types): drop by protocol, drop by source IP, drop by port, hashlimit, connlimit, SYN cookies, ICMP rate-limit
• ipset: create sets, add source IPs for high-performance bulk blocking
• nftables: drop rules, rate limiting, source blocking
• UFW: deny by protocol, source, or port
• firewalld: rich rules for dropping by source, port, or protocol
• tc (traffic control): ingress policing, egress TBF shaping
• Null routes: blackhole by source or destination IP
• fail2ban: ban IPs in existing jails
• Nginx L7: deny by user agent, deny by path, rate limiting, geo blocking
• Apache L7: deny by user agent, deny by path
• XDP/eBPF: kernel-bypass packet filtering for extreme PPS attacks, rate-limiting by PPS

Every rule has a live command preview before execution, risk warnings for broad rules, cooldown timers to prevent repeated firing, and a full audit trail with exact command history. Rules auto-undo when the incident resolves.

Safety: Automated Rollback

Aggressive mitigation can cause collateral damage. A broad blackhole or drop-all rule might stop the attack but also kill legitimate traffic. Flowtriq has automated rollback to catch this.

After deploying a broad rule (blackhole, drop_all, or scrubbing diversion), the engine monitors traffic levels. If traffic drops more than 90%, that is a signal the rule is too aggressive and is blocking good traffic. Flowtriq automatically:

1. Withdraws the offending rule
2. Deploys a more targeted replacement (for example, replacing a full blackhole with a protocol-specific rate-limit)
3. Logs the entire rollback with both the original and replacement rules for forensic review

This means you can enable aggressive auto-escalation without the fear that a false positive will take down your own service.

Event Queue and Orchestration

Behind all of this is an event-driven orchestration engine that prevents rule storms, handles concurrent attacks across multiple nodes, and ensures every action is auditable.

• Priority queue: events are processed by severity (critical=90, high=70, medium=50, low=30)
• Attack aggregation: multi-node events targeting the same prefix are collapsed within a configurable window (default 5 seconds), producing one mitigation rule instead of fifty
• Deduplication: if the same target, protocol, port, and intent combination already has an active rule, the existing rule's TTL is refreshed instead of creating a duplicate
• Sliding-window rate limiting: a configurable cap on rules per minute (default 30) prevents the engine from overwhelming your BGP speaker during an attack storm
• Cooldown anti-flap: a 60-second default cooldown prevents oscillating attacks from creating rapid deploy/withdraw cycles
• Distributed locking: MySQL advisory locks ensure safety when multiple Flowtriq processes are running concurrently
• Exponential backoff retry: failed deployments retry at 30s, 60s, 120s, 240s, 480s intervals (max 5 retries)
• TTL-based auto-expiry: every rule has a time-to-live (default 300 seconds). When it expires, the rule is automatically withdrawn
• Global safety limit: maximum 200 active rules per tenant, preventing runaway automation

Observability

Every action the mitigation engine takes is logged and exportable:

• Prometheus metrics: /api/metrics endpoint exposes active rules, pending deployments, failures, queue depth, and per-adapter health
• Kafka export: stream mitigation events to Kafka topics for integration with your SIEM or data pipeline
• Full audit log: every create, announce, refresh, withdraw, escalate, fail, retry, expire, and rollback action is recorded with timestamps and exact adapter payloads
• Adapter health history: latency tracking over time with alerts on state transitions

Additional Capabilities

Country Lockdown (Geo-Based FlowSpec)

Automatically generate FlowSpec drop or rate-limit rules based on source country during an active attack. Configurable per-tenant and per-host country lists. Useful for services that only serve specific regions and can safely block traffic from others during an incident.

Dynamic Baseline Thresholds

The escalation thresholds themselves can be dynamic. Flowtriq learns your 168-hour weekly traffic pattern (hour-of-week cycle) and auto-adjusts thresholds based on historical averages plus a configurable deviation percentage. Static thresholds serve as a floor so the system never drops below your configured minimums.

Per-Host Threshold Overrides

Individual IPs can have custom escalation thresholds, geo lockdown lists, and labels for identifying critical infrastructure. A game server running at 2 Gbps baseline needs different thresholds than a web server running at 50 Mbps.

Connection Tracking and Stateful Analysis

The engine enriches attack context with stateful analysis: SYN ratio detection (identifying SYN floods when SYN packets exceed 80% with ACKs below 10%), state exhaustion detection (many SYNs and ACKs but no FINs), and asymmetric traffic detection (inbound/outbound ratio exceeding 50:1). This context produces more accurate mitigation rules.

RPKI Validation

All unicast BGP announcements go through RPKI validation before deployment. The engine checks against the Cloudflare public RPKI API (or a custom Routinator instance) with a 1-hour cache. If a prefix is RPKI-invalid, the system warns in the mitigation log to prevent upstream rejection.

BGP Subnet Auto-Discovery

Instead of manually configuring which prefixes to protect, Flowtriq can learn your monitored prefixes directly from BGP peers via GoBGP, BIRD 2, or FRR. This eliminates configuration drift as your prefix list changes.

sFlow/NetFlow/IPFIX Flow Mirroring

In addition to the native flow ingestion described above, Flowtriq can mirror flow data to multiple destinations via UDP. This lets you feed the same sFlow/NetFlow/IPFIX telemetry to your existing NMS, SIEM, or capacity planning tools alongside Flowtriq, with per-tenant mirror configuration.

How It All Fits Together

The full mitigation lifecycle looks like this:

1. Detection: the Flowtriq agent detects an attack within 1 second by reading /proc/net/dev and merging upstream flow telemetry (sFlow, NetFlow, IPFIX) from your routers, comparing the higher reading against dynamic baselines
2. Classification: the attack is classified into one of 8 families (UDP flood, SYN flood, DNS amplification, etc.) with a confidence score
3. PCAP capture: a pre-attack ring buffer of 1,000 packets is preserved as forensic evidence
4. Alerts: notifications fire across your configured channels (Discord, Slack, PagerDuty, etc.) within the same second
5. Local mitigation: if auto-mitigation rules are configured, the agent deploys firewall rules on the node immediately
6. BGP escalation: the mitigation engine evaluates the attack against escalation thresholds and deploys FlowSpec, RTBH, or scrubbing diversion as needed
7. Monitoring: the engine watches for collateral damage and automatically rolls back overly aggressive rules
8. Resolution: when the attack stops, rules are withdrawn, scrubbing diversions are removed, and resolution alerts fire
9. Audit: the full timeline is preserved in the audit log with exact adapter payloads for post-incident review

Every step is automated. Every step is logged. And every step can be configured, overridden, or disabled per tenant, per node, or per IP.

Back to Blog