The Question We Hear From Everyone Coming Off Legacy Hardware
Operators who have run Arbor, Corero, Path.net, or any hardware-based scrubbing solution for a long time walk in with a specific mental model: protection capacity equals hardware capacity. The Arbor appliance sits in your rack, traffic flows through it, and the box's port speed and CPU dictate what it can handle. That model is completely reasonable, but it's not how Flowtriq works.
The question we hear most often from these operators:
"Okay, so the capacity will be that of the port?"
The answer is no. And understanding why requires understanding the architectural difference between inline hardware scrubbing and what Flowtriq actually does.
What Legacy Hardware Scrubbing Does
Traditional DDoS mitigation hardware (Arbor TMS, Corero SmartWall, the AMD Ryzen-based appliances some providers custom-build) sits inline in the traffic path. All traffic goes into the box, the box inspects it and drops attack traffic, and clean traffic comes out the other side. If 100 Gbps of attack traffic hits a 10G port, the port saturates and the device is overwhelmed before it can filter anything. The protection capacity is literally capped by the hardware.
This model works well at very large scale where the scrubbing infrastructure has excess capacity over any realistic attack, think dedicated scrubbing centers with 1+ Tbps of inline capacity. For individual servers or data centers without that kind of headroom, it creates a hard ceiling: your protection is only as good as your hardware.
What Flowtriq Does Instead
Flowtriq is not inline. The agent does not sit in the traffic path. It does not inspect every packet before forwarding it. Instead, it monitors traffic at the host and uses the very first moments of an attack, before your server is overwhelmed, to get everything it needs off the box.
Here is what happens in the first seconds of a real attack, in order:
First malicious packets arrive at the server's network interface. The Flowtriq agent is already monitoring per-second traffic counters across PPS, BPS, source diversity, protocol distribution, and port patterns.
The agent detects the anomaly against the dynamic baseline within the first fraction of a second. It immediately streams the traffic telemetry (attack fingerprint, source distribution, protocol breakdown, packet characteristics) to Flowtriq's infrastructure. This happens while the server is still responsive, before the attack has had time to saturate the link or overwhelm the host.
From this point, all processing happens on Flowtriq's servers, not yours. Attack classification runs (9 families, confidence scored). BGP FlowSpec or RTBH rules are generated. Cloud scrubbing integrations are triggered. Your notification channels (Slack, PagerDuty, Discord, etc.) are alerted. PCAP evidence is flagged for capture.
BGP FlowSpec rules are pushed to your upstream router. Traffic matching the attack fingerprint is dropped at the network edge, before it ever reaches your server's port. Your server comes back up as attack traffic is filtered upstream. If cloud scrubbing is configured, traffic is rerouted through the scrubbing center.
Even if your server is completely non-responsive from the attack (fully saturated, kernel panic, whatever), Flowtriq already has everything it needs. The mitigation pipeline is running on Flowtriq's infrastructure. BGP rules are up. You're getting alerts. The server doesn't need to be alive for the response to work.
Why This Architecture Removes the Port Capacity Ceiling
When Flowtriq pushes a BGP FlowSpec rule to your upstream router, that rule is enforced at the router, not at your server. Your upstream router drops traffic matching the attack fingerprint before it transits to your network, before it hits your peering links, and long before it reaches your server's port.
A 500 Gbps attack against a server on a 10G port: your server's port would be saturated in milliseconds without mitigation. But Flowtriq detected the attack in the first 0.1–0.5 seconds, streamed the telemetry to its infrastructure, generated the BGP rule, and pushed it to your upstream router. The router is now dropping the 500 Gbps of attack traffic at the edge. Your 10G port sees clean traffic again. The capacity constraint of the server port is irrelevant once upstream mitigation is active.
The server's port is not the mitigation layer. The upstream router is the mitigation layer. Flowtriq's job is to detect fast enough to get a rule to the router before your port is saturated, and to do it automatically, without you having to make a phone call to your transit provider.
Two Deployment Models, Same Architecture
Flowtriq can be deployed two ways, and both work on the same principle:
On-node agent (ftagent)
Install the Flowtriq agent directly on each server you want to protect. The agent monitors traffic at the host's network interface, unsampled, per-second, on every packet. This gives you per-server granularity: exact source IP census, full protocol breakdown, attack classification down to port and packet-size patterns, and automatic PCAP capture with a pre-attack buffer.
Best for: bare metal servers, VPS fleets, cloud instances, any server-level deployment. No network infrastructure prerequisites.
pip install ftagent --break-system-packages
Router flow ingestion
For large-scale deployments (multiple data centers, ISP-scale infrastructure, or situations where deploying agents on individual servers isn't practical) Flowtriq can ingest NetFlow, sFlow, or IPFIX from your routers directly. This gives you network-wide coverage across your full IP space from a single ingestion point.
Best for: hosting providers, ISPs, operators with existing flow export infrastructure who want network-wide visibility without per-server agents.
In either case, the mitigation pipeline is the same: Flowtriq's infrastructure handles BGP automation, cloud scrubbing, alerting, and analysis. Your servers or routers provide the telemetry; Flowtriq provides the response.
On-Node vs Flow Ingestion: What to Choose
Choose on-node agents when you need maximum detection depth per server: exact source IP counts, attack family classification, PCAP capture, and per-second granularity down to the packet level. Agents work on any Linux server without any network infrastructure changes. This is the right choice for most operators protecting specific servers.
Choose router flow ingestion when you have multiple data centers with existing NetFlow/sFlow export infrastructure, and you want network-wide coverage across a large IP space from a centralized ingestion point. This is more common for ISPs and large hosting providers. Note that flow sampling introduces some detection granularity tradeoffs at the server level compared to on-node agents. See our comparison guide for detail.
Run both when you have a mix of critical individual servers that need deep per-server detection (agents) and a large IP space that needs network-wide coverage (flow ingestion). BGP mitigation, cloud scrubbing, alerting, and attack analysis work identically across both deployment modes.
What "All Integrations Work Either Way" Actually Means
Whether you deploy on-node agents, router flow ingestion, or both, every Flowtriq integration operates the same way, because they all run on Flowtriq's infrastructure, not on your servers:
- BGP FlowSpec and RTBH: Flowtriq pushes BGP route announcements to your upstream router via ExaBGP, GoBGP, BIRD 2, or FRRouting when an attack is detected. Configured once; fires automatically on every qualifying incident.
- Cloud scrubbing: Integrations with Cloudflare, AWS, Azure, and other scrubbing providers are triggered by Flowtriq's infrastructure when attacks exceed configured thresholds. Your servers don't initiate these calls.
- Notifications: Slack, Discord, PagerDuty, OpsGenie, SMS, email, and custom webhooks all fire from Flowtriq's servers. An alert reaches your team in under 3 seconds from the moment the anomaly is detected, regardless of what your server is doing.
- Attack analysis and PCAP: Classification runs on Flowtriq's infrastructure. PCAP is captured on the node (for on-node deployments) and uploaded automatically. The incident record is fully populated before you even open the alert.
Common Questions
What if my server is completely knocked offline before Flowtriq can stream data?
The data streaming happens in the first 0.1–0.5 seconds of a traffic baseline breach, during the ramp-up of the attack, before volumetric attacks typically reach their peak. In practice, the data is off the server before it's overwhelmed in the vast majority of real attack scenarios. In the rare case of an instantaneous very-high-volume flood that saturates the link before detection can fire, router flow ingestion (which doesn't depend on the server being alive at all) is the appropriate deployment model to use alongside or instead of on-node agents.
Do I need my own BGP/ASN for the upstream mitigation to work?
Yes, for BGP-based upstream mitigation (FlowSpec or RTBH), you need a BGP session with your upstream transit provider and enough routing flexibility to announce mitigation routes. Most hosting providers and ISPs already have this. If you don't, Flowtriq's on-node firewall rules (iptables/nftables) handle mitigation locally. These apply to traffic that reaches your server, so they're effective for attacks that don't saturate the link, which is the majority of real-world incidents.
How is this different from Arbor or Corero?
Arbor and Corero are inline hardware appliances. Traffic flows through the device, which inspects and filters it before passing it along. Protection capacity is bounded by the hardware's port speed and CPU. Flowtriq is not inline: it monitors traffic from the side, uses the first fraction of a second of an attack to capture telemetry, and orchestrates upstream mitigation that stops attack traffic before it reaches your infrastructure. There is no hardware to buy, no rack space to provision, and no port speed ceiling on the mitigation layer.
What happens to detection if the agent server goes down?
If you're using router flow ingestion, detection continues independently of any individual server being up or down, the router keeps exporting flows regardless. If you're using on-node agents only, a server that's completely offline generates no traffic to detect. In production environments with uptime requirements, running both deployment modes is the belt-and-suspenders approach: agents for depth on critical servers, flow ingestion for network-wide coverage.
See it working on your own infrastructure
Install in under 2 minutes on any Linux server. Detection starts immediately. BGP, scrubbing, and alerting integrations configure in the dashboard. 7-day free trial, no credit card.
Start Free Trial →