Why ISPs Need Per-Node Detection
Most enterprise DDoS solutions were designed for a single site: one data center, one uplink, one set of IPs to protect. ISPs operate in a fundamentally different environment. You have dozens or hundreds of edge routers, each serving a different set of customer prefixes. An attack on one customer's /24 looks like normal background traffic at your core - until that customer's port saturates and their tickets start flooding your NOC.
The traditional approach - centralized NetFlow collection and sampling - has three critical problems for ISP-scale detection:
- Sampling blindness: At 1:1000 or 1:4096 sampling rates (common on high-throughput edge routers), short-duration attacks and low-volume application-layer floods are statistically invisible. A 500 Kpps SYN flood to a customer's web server might produce only 120-500 sampled flows per second - well below most detection thresholds.
- Latency: NetFlow export intervals (typically 1-5 minutes) combined with collector processing time means 3-10 minutes between attack start and first alert. For a 10 Gbps volumetric attack, that is 225-750 GB of attack traffic delivered before you even know about it.
- Prefix coverage gaps: Centralized collectors see aggregated traffic. Detecting that a specific /28 within a customer's /24 is under attack requires per-prefix baselining that most NetFlow tools do not support at scale.
Per-node detection solves all three. A lightweight agent running on each edge router or adjacent monitoring host analyzes traffic in real time - every packet, no sampling. Detection happens at the point of ingress, where attack traffic is most visible and where mitigation can be applied immediately.
The difference between sampled and per-packet detection is not incremental. A 1:1000 sampling rate does not give you 99.9% coverage - it gives you a statistical approximation that misses entire attack categories. Per-node detection is a different class of visibility.
The Challenge: Monitoring Thousands of Customer Prefixes
A mid-size regional ISP might announce 500-2,000 customer prefixes across 50-200 edge routers. A national provider could have 10,000+ prefixes across 500+ nodes. Each prefix has its own traffic profile, its own baseline, and its own definition of "normal." A hosting customer running game servers has a very different traffic pattern than a municipal government running a public website.
Effective ISP-scale detection requires solving three problems simultaneously:
1. Per-prefix baselining
You cannot use a single threshold for all customer prefixes. A 50 Kpps spike to a hosting customer's /24 might be a Tuesday afternoon; the same spike to a small business /28 is almost certainly an attack. Detection must learn the normal traffic profile for each prefix independently and alert on deviations from that specific baseline.
2. Multi-dimensional classification
Volume alone does not tell you enough. ISP-grade detection needs to classify by protocol distribution (UDP/TCP/ICMP ratios), packet-size distribution (small-packet floods vs amplification), source entropy (distributed botnet vs single reflector pool), and geographic distribution. A sudden shift from 80% TCP to 80% UDP on a prefix that normally serves web traffic is a strong attack signal even if total PPS has not spiked dramatically.
3. Customer attribution
When an alert fires, the NOC needs to know immediately: which customer is affected, what service they run, what their SLA tier is, and who to notify. Detection without attribution is just noise.
Flowtriq handles all three by running a lightweight agent on each edge node. Each agent maintains per-prefix baselines, performs multi-dimensional traffic classification, and maps detected incidents to customer records via prefix-to-customer mapping configured in the dashboard.
Deploying Flowtriq's Lightweight Agent
The Flowtriq agent is a single statically compiled binary that runs on Linux, FreeBSD, and most router OS environments that support containerized services (Junos cRPD, IOS-XR AppHosting, Nokia SR Linux, VyOS). It consumes minimal resources because it performs detection locally and sends only metadata (alerts, metrics, baselines) to the Flowtriq cloud - never raw traffic.
Resource Usage per Node ────────────────────────────────────────────────── CPU 1 core (2% avg on modern x86) Memory 128-256 MB depending on prefix count Disk ~50 MB binary + 200 MB working state Bandwidth < 1 Mbps metadata to Flowtriq API Install time < 2 minutes (curl | bash or pkg)
For ISPs, there are three common deployment patterns:
Pattern 1: Direct on edge routers
For routers that support application hosting (Juniper MX with Junos Evolved, Cisco IOS-XR with AppMgr, Nokia SR Linux), the Flowtriq agent runs as a container directly on the router. It reads traffic from a local mirror port or packet broker tap. This is the lowest-latency option - detection happens on the same box that will apply FlowSpec or firewall rules.
Pattern 2: Adjacent monitoring hosts
For routers without application hosting or for ISPs who prefer not to run third-party code on production routers, deploy a small Linux host (physical or VM) at each POP connected to a mirror/SPAN port. The Flowtriq agent runs on this host and analyzes mirrored traffic. A single 1U server or VM can monitor multiple router ports simultaneously.
Pattern 3: Customer CPE agents
For managed service customers who want DDoS detection as a value-added service, deploy the Flowtriq agent on customer premises equipment. This provides per-customer visibility and enables customer-facing incident dashboards. CPE agents report to the ISP's Flowtriq workspace, giving the NOC unified visibility across the entire customer base.
Hybrid deployments are common. Most ISPs use Pattern 1 or 2 for their own edge infrastructure and Pattern 3 for high-value managed service customers. Flowtriq treats all three patterns identically - every agent is a node in your workspace, regardless of where it runs.
BGP FlowSpec Integration: Surgical Mitigation
ISPs have a mitigation tool that most enterprises lack: BGP FlowSpec. While enterprises typically rely on upstream providers to apply FlowSpec rules on their behalf, ISPs are the upstream provider. You control the routers, the BGP sessions, and the TCAM. FlowSpec lets you filter attack traffic surgically - dropping specific protocol/port/size combinations while legitimate traffic flows uninterrupted.
The alternative - RTBH (Remotely Triggered Black Hole routing) - is a blunt instrument. Blackholing a customer's /32 stops the attack but also takes their service offline. For an ISP, that means an SLA violation, a credit on the next invoice, and a customer evaluating your competitors. FlowSpec avoids this entirely.
Mitigation Method Customer Impact Precision ISP Risk ────────────────────────────────────────────────────────────────────────── FlowSpec None (attack only) High Low RTBH Total outage None SLA violation ACL (manual) None if correct High Slow, error-prone Cloud scrubbing Slight latency add High Cost per Gbps
Flowtriq integrates with FlowSpec by running an ExaBGP or GoBGP instance as a BGP adapter. When an attack is detected and classified, Flowtriq generates FlowSpec rules based on the attack signature and injects them via the BGP adapter to your route reflectors, which propagate them to all edge routers in the path. Rules deploy in seconds, not minutes.
For example, a DNS amplification attack hitting customer 198.51.100.0/24 produces FlowSpec rules that drop UDP from source port 53 with packet length > 512 bytes - surgical filtering that blocks only the amplified DNS replies while the customer's legitimate DNS traffic continues normally.
4-Level Auto-Escalation
Not every attack warrants the same response. A 50 Kpps UDP flood can be handled by a local firewall rule; a 40 Gbps amplification attack needs FlowSpec or RTBH at the edge; a sustained 200+ Gbps attack may require diverting traffic to a cloud scrubbing provider. Flowtriq's auto-escalation chain handles all of these automatically, without NOC intervention.
Level 1: Local firewall
For attacks within the node's local handling capacity, Flowtriq deploys iptables or nftables rules directly on the target host or adjacent monitoring box. This is instantaneous (sub-second deployment) and does not require any BGP changes. Effective for small floods, single-source attacks, and application-layer probes.
Level 2: BGP FlowSpec
When attack volume exceeds local filtering capacity or when the attack has identifiable L3/L4 signatures that merit network-edge filtering, Flowtriq escalates to FlowSpec. Rules propagate to all edge routers via BGP, filtering attack traffic before it reaches the target link. The customer stays online.
Level 3: RTBH (BGP blackhole)
When FlowSpec cannot contain the attack - because the traffic is too generic to filter surgically, the attack volume exceeds the capacity of upstream links before FlowSpec can take effect, or the upstream transit provider does not support FlowSpec - Flowtriq escalates to RTBH. The target prefix is blackholed at the provider edge, stopping all traffic. This is the last resort before cloud scrubbing.
Level 4: Cloud scrubbing redirect
For attacks that exceed your entire network's absorption capacity, or when the target prefix cannot tolerate any downtime (RTBH is not acceptable), Flowtriq triggers a GRE or BGP-based redirect to a cloud scrubbing provider. Clean traffic is returned via a GRE tunnel or direct cross-connect. Flowtriq supports integration with major scrubbing providers including Path.net, Voxility, and others.
Escalation Chain — Typical ISP Configuration ────────────────────────────────────────────────────────────────────── Level 1 │ Local firewall │ < 200 Kpps │ iptables/nftables Level 2 │ BGP FlowSpec │ 200 Kpps - 5 Mpps │ Surgical L3/L4 filter Level 3 │ RTBH (blackhole) │ 5 Mpps - 50 Mpps │ Full prefix blackhole Level 4 │ Cloud scrubbing │ > 50 Mpps │ GRE redirect to scrubber ────────────────────────────────────────────────────────────────────── All thresholds are configurable per node, per prefix, and per customer.
De-escalation is automatic too. When attack volume drops below a tier's threshold for a configurable cooldown period (default: 5 minutes), Flowtriq steps down one level. FlowSpec rules are withdrawn, blackholes are lifted, and scrubbing redirects are removed. Every escalation and de-escalation event is logged in the audit trail with full details.
The escalation chain is fully customizable per customer. A platinum SLA customer might skip RTBH entirely and escalate directly from FlowSpec to cloud scrubbing. A budget customer might stop at RTBH. Flowtriq lets you define per-customer escalation policies that match your SLA tiers.
Alert Routing: Per-Customer Incident Channels
ISP NOC teams deal with a firehose of alerts. If every detected attack on every customer prefix generates a PagerDuty notification, your on-call engineers will be buried within hours. Flowtriq solves this with granular alert routing - different customers, different channels, different escalation paths.
- Per-customer notification channels: Route alerts for Customer A to their dedicated Slack channel, Customer B to email, and Customer C to a webhook that triggers their own monitoring system. Each customer's alerts stay in their own lane.
- NOC dashboard: A unified real-time dashboard shows all active incidents across all nodes and customers, with filtering by severity, customer, prefix, attack type, and mitigation status. Your NOC sees the big picture without drowning in individual notifications.
- Severity-based routing: Level 1 (local firewall) mitigations might only log to the dashboard. Level 2 (FlowSpec) triggers a Slack notification. Level 3 (RTBH) pages the on-call engineer. Level 4 (cloud scrubbing) pages the NOC manager. You define the mapping.
- Customer-facing portals: For managed DDoS protection customers, Flowtriq provides read-only incident views that you can share with the customer. They see their own attacks and mitigations without accessing your full dashboard.
- Integration with existing ITSM: Flowtriq's webhook and API integrations connect to ServiceNow, Jira, PagerDuty, OpsGenie, and any system that accepts HTTP webhooks. Auto-create tickets for every incident above a severity threshold.
Discord and Slack channels per customer: A common ISP pattern is creating a shared Slack or Discord channel between your NOC and each customer. Flowtriq sends incident alerts directly to these shared channels, so your customer sees the detection, the classification, and the mitigation action in real time - before they even notice the attack.
Cost Comparison: Flowtriq vs Arbor Sightline
The elephant in the ISP DDoS detection room is NETSCOUT Arbor Sightline (formerly Arbor Peakflow). It is the incumbent, it is capable, and it is expensive. Here is a realistic cost comparison for a 200-node ISP network:
Arbor Sightline Flowtriq ────────────────────────────────────────────────────────────────────── License model Annual enterprise Per-node monthly Base platform cost $100,000-250,000/yr $0 Per-node cost Included (but capped) $9.99/mo ($7.99/yr) 200-node annual cost $150,000-300,000+ $19,176/yr (annual) Hardware (collectors) $30,000-80,000 None (runs on existing) Implementation $20,000-50,000 (PS) Self-service (< 1 day) Training $5,000-10,000 Included (docs + support) FlowSpec integration Arbor TMS (additional) Built-in ────────────────────────────────────────────────────────────────────── Year 1 total $205,000-390,000+ $19,176 Year 2+ total $150,000-300,000+/yr $19,176/yr
The math is stark. At $9.99 per node per month ($7.99 on annual billing), a 200-node Flowtriq deployment costs $19,176 per year on annual billing. That is roughly 8-15x cheaper than Arbor Sightline for equivalent detection coverage. And Flowtriq includes FlowSpec-based mitigation in every plan - Arbor requires the separate TMS (Threat Mitigation System) appliance for automated mitigation, which adds another $50,000-150,000.
Beyond licensing, Flowtriq eliminates the hardware cost entirely. Arbor Sightline requires dedicated collector appliances (physical or VM) to process NetFlow data. Flowtriq's agent runs on existing router infrastructure or lightweight monitoring hosts you already have at each POP.
Flowtriq offers a free 7-day trial on all plans. For ISPs evaluating detection tools, this means you can deploy agents across a subset of your network, run real traffic through the detection engine, and validate alert accuracy before committing. No purchase orders, no sales calls, no 90-day POC paperwork.
Real Deployment Scenario: 200-Node ISP Network
Let us walk through a realistic deployment for a regional ISP with 200 edge nodes across 12 POPs, serving approximately 4,000 customer prefixes.
Network topology
- 12 POPs across a metropolitan or regional footprint
- 200 edge routers (mix of Juniper MX, Cisco ASR, and Nokia 7750)
- 4 core routers running iBGP with route reflectors
- 3 upstream transit providers (e.g., Cogent, Lumen, Hurricane Electric)
- 2 IXP peering points
- ~4,000 customer prefixes (mix of /24 to /28)
Deployment plan
- Day 1 - Install agents on 10 nodes at your highest-traffic POP. Validate detection accuracy and alert formatting. Takes approximately 30 minutes including configuration.
- Day 2-3 - Review baselines. Flowtriq automatically learns per-prefix traffic baselines within 24-48 hours. Check that baseline thresholds make sense for your known traffic patterns. Adjust sensitivity if needed.
- Day 4-5 - Roll out to remaining 190 nodes. Use your existing configuration management (Ansible, Salt, Puppet) or Flowtriq's bulk provisioning API. Each agent install takes under 2 minutes. At 190 nodes, budget 2-3 hours including spot-checks.
- Day 5 - Configure BGP adapter. Deploy ExaBGP or GoBGP on a dedicated VM, establish iBGP sessions with your route reflectors, and configure the FlowSpec address family. Connect the adapter to Flowtriq via the dashboard.
- Day 6 - Set up alert routing. Map customer prefixes to notification channels. Configure NOC dashboard views. Set escalation policies per customer SLA tier.
- Day 7 - Enable auto-mitigation. Start with approval-required mode (Flowtriq proposes mitigation actions, NOC engineer approves with one click). Once you trust the detection accuracy, switch high-confidence attack types to fully automatic.
Deployment Timeline — 200 Nodes ────────────────────────────────────────────────────────────────────── Day 1 │ Pilot: 10 nodes at primary POP Day 2-3 │ Baseline learning + validation Day 4-5 │ Full rollout: 190 remaining nodes + BGP adapter Day 6 │ Alert routing + customer notification channels Day 7 │ Auto-mitigation enabled (approval mode) Day 14+ │ Full auto-mitigation for high-confidence attack types ────────────────────────────────────────────────────────────────────── Total deployment time: < 1 week for full production coverage
Ongoing operations
Once deployed, the system is largely autonomous. Baselines adapt continuously, detection runs 24/7, and mitigation fires automatically. Your NOC team's role shifts from manually detecting and responding to attacks to reviewing automated actions, tuning thresholds for edge cases, and managing customer escalation policies. Most ISPs find that Flowtriq reduces DDoS-related NOC workload by 70-90%.
Integration with Upstream Transit Providers
ISPs do not operate in isolation. Your upstream transit providers are critical partners in DDoS mitigation, especially for attacks that exceed your own network's capacity. Flowtriq integrates with upstream providers at two levels:
FlowSpec propagation to upstream
If your transit provider accepts FlowSpec announcements via BGP (increasingly common), Flowtriq's BGP adapter can inject FlowSpec rules that propagate upstream. This means attack traffic is filtered at your provider's edge - before it even reaches your network. The following providers are known to accept customer FlowSpec:
- Path.net: Full FlowSpec support with automated DDoS protection. Flowtriq's BGP adapter integrates directly with Path.net's FlowSpec-capable edge.
- Voxility: Accepts FlowSpec from customers on supported plans. Commonly used by European ISPs for upstream filtering.
- Cogent: Supports RTBH communities; FlowSpec support available on enterprise transit plans. Flowtriq falls back to RTBH when FlowSpec is unavailable.
- Lumen (CenturyLink): Supports RTBH and FlowSpec on select platforms. Check with your account team for availability on your specific circuit.
- Hurricane Electric: Supports RTBH communities. FlowSpec support varies by peering location.
- NTT: Full FlowSpec and RTBH support on transit services.
- GTT: RTBH support standard; FlowSpec available on DDoS-protected transit plans.
Cloud scrubbing provider integration
For Level 4 escalation, Flowtriq orchestrates traffic diversion to cloud scrubbing providers. When attack volume exceeds what FlowSpec and RTBH can handle (or when the target cannot tolerate any downtime), Flowtriq announces more-specific routes or triggers GRE tunnel activation to redirect traffic through a scrubbing center.
The integration is provider-agnostic. Any scrubbing service that accepts traffic via BGP announcement or GRE tunnel can be configured as a Level 4 target. Flowtriq handles the announcement lifecycle: activating the redirect when the attack escalates, monitoring scrubbed traffic for residual attack leakage, and withdrawing the announcement when the attack subsides.
Multi-provider failover: Flowtriq supports configuring multiple upstream providers and scrubbing services as mitigation targets, with priority ordering and automatic failover. If your primary transit provider's FlowSpec session goes down, Flowtriq automatically routes FlowSpec rules through your secondary provider. If your primary scrubbing provider is at capacity, traffic diverts to the backup.
What ISPs Should Evaluate
When comparing DDoS detection platforms for ISP-scale deployment, here are the questions that matter:
- Per-packet or sampled? If the vendor relies on NetFlow/sFlow sampling, ask what sampling rates they require and how they handle sub-threshold attacks. Per-packet detection catches attacks that sampling misses entirely.
- Per-node or centralized? Centralized architectures add latency and create single points of failure. Per-node detection is faster and more resilient.
- FlowSpec or RTBH only? If the platform only supports RTBH for automated mitigation, every mitigation action takes the customer offline. FlowSpec keeps them online.
- Auto-escalation? Can the platform automatically escalate from local filtering to FlowSpec to RTBH to cloud scrubbing? Or does each step require manual intervention?
- Per-customer alert routing? Can you route alerts for different customers to different channels with different severity thresholds? Or does every alert go to the same NOC queue?
- Pricing at scale? What does the platform cost at 200 nodes? At 500? At 1,000? Per-node pricing scales linearly and predictably. Enterprise licensing often comes with hidden per-Gbps or per-prefix surcharges.
- Deployment complexity? Does the platform require dedicated hardware, professional services, or weeks of implementation? Or can your team deploy it in a day?
Getting Started
ISP-scale DDoS detection does not have to mean six-figure budgets and six-month deployments. Flowtriq's per-node architecture was built for networks like yours: distributed, heterogeneous, and operating at a scale where centralized sampling falls short.
At $9.99 per node per month ($7.99 on annual billing), you can deploy real-time, per-packet detection across your entire edge with built-in FlowSpec mitigation, 4-level auto-escalation, and per-customer alert routing. A 200-node deployment costs less than $20,000 per year - a fraction of what you would spend on a single Arbor Sightline license.
Start with Flowtriq's free 7-day trial. Deploy agents on 10 nodes at your busiest POP, let baselines learn for 48 hours, and see what your network looks like with per-packet visibility. No contracts, no sales calls, no hardware to rack.
Back to Blog