The ISP DDoS Challenge
Internet service providers face a fundamentally different DDoS challenge than single-server operators or enterprise networks. An ISP does not protect one application or one website. It protects thousands of subscribers, each with their own IP addresses, their own traffic patterns, and their own risk profiles. A 5 Gbps attack targeting one subscriber's IP can saturate shared infrastructure and degrade service for every other subscriber on the same aggregation link.
ISPs also operate under constraints that other organizations do not. You cannot simply block suspicious traffic at the edge because that traffic might be legitimate for another subscriber. You cannot deploy per-subscriber firewalls at scale. And you have regulatory obligations around service availability, customer notification, and abuse management that add complexity to every mitigation decision.
The good news is that ISPs have a significant advantage: BGP. As the operator of your own autonomous system, you control the routing infrastructure. BGP FlowSpec lets you deploy surgical filtering rules across your entire network in seconds. RTBH (Remote Triggered Black Hole) routing lets you divert attack traffic upstream before it enters your network. These are powerful tools, but they need an intelligent detection layer to trigger them. That is where Flowtriq comes in.
This playbook covers end-to-end DDoS operations for ISPs: configuring flow-based detection with sFlow, deploying automated BGP mitigation, building per-subscriber detection profiles, notifying affected customers, and maintaining compliance documentation.
Step 1: Configure Flow Sources (sFlow)
Flow-based detection is the standard approach for ISP-scale DDoS monitoring. Rather than inspecting every packet (which is impossible at 100 Gbps+), your routers and switches sample traffic and export flow records to a collector. Flowtriq ingests these flow records and analyzes them in real-time.
We recommend sFlow for ISP deployments because it provides consistent, low-overhead sampling that scales linearly with link speed. Configure sFlow on your edge and aggregation routers to export to the Flowtriq agent:
Juniper MX Series
set protocols sflow polling-interval 20 set protocols sflow sample-rate ingress 2048 set protocols sflow sample-rate egress 2048 set protocols sflow collector 10.0.0.100 udp-port 6343 set protocols sflow interfaces xe-0/0/0 set protocols sflow interfaces xe-0/0/1 set protocols sflow interfaces ae0
Cisco IOS-XR
flow exporter FLOWTRIQ destination 10.0.0.100 transport udp 6343 source Loopback0 flow monitor FLOWTRIQ-MONITOR exporter FLOWTRIQ record ipv4 interface TenGigE0/0/0/0 flow ipv4 monitor FLOWTRIQ-MONITOR sampled flow ipv4 sampler 1 out-of 2048
Choosing a Sample Rate
The sample rate determines how many packets are examined per flow record. A 1:2048 sample rate means one in every 2,048 packets is sampled. For ISP edge routers handling 10 Gbps or more, we recommend:
- 10 Gbps links: 1:2048 sample rate
- 40 Gbps links: 1:4096 sample rate
- 100 Gbps links: 1:8192 sample rate
Lower sample rates (more sampling) provide better detection accuracy but generate more flow records. The Flowtriq agent handles up to 100,000 flow records per second per instance, which is sufficient for most ISP deployments.
Step 2: Deploy Flowtriq Agents
Install a Flowtriq agent on a server that receives the sFlow exports. For ISP deployments, we recommend dedicating a server (physical or virtual) to Flowtriq rather than sharing it with other services:
curl -s https://get.flowtriq.com | bash flowtriq-agent configure \ --api-key YOUR_API_KEY \ --flow-source sflow \ --listen-port 6343 \ --mode isp
The --mode isp flag enables ISP-specific features: per-subscriber detection, customer prefix mapping, and BGP mitigation provider support. The agent begins ingesting flow records immediately and establishes per-prefix traffic baselines within 24 to 48 hours.
For larger ISPs with multiple points of presence, deploy an agent at each POP to analyze traffic locally. Each agent reports to the same Flowtriq dashboard, giving you a centralized view of your entire network.
Step 3: Per-Subscriber Detection Profiles
ISPs need to detect attacks at the subscriber level, not just at the network level. A 500 Mbps UDP flood targeting one residential customer is a critical incident for that customer, even though it is a tiny fraction of your aggregate traffic. Flowtriq builds individual traffic baselines for each subscriber prefix:
{
"subscriber_detection": {
"enabled": true,
"prefix_source": "bgp_rib",
"baseline_period_hours": 72,
"thresholds": {
"residential": {
"bps_multiplier": 10,
"pps_multiplier": 15,
"absolute_bps_min": 100000000
},
"business": {
"bps_multiplier": 5,
"pps_multiplier": 8,
"absolute_bps_min": 500000000
},
"hosting": {
"bps_multiplier": 3,
"pps_multiplier": 5,
"absolute_bps_min": 1000000000
}
}
}
}
The prefix_source field tells Flowtriq where to get your subscriber prefix list. Options include bgp_rib (learned from your BGP RIB via BMP), static (a manually maintained list), or radius (dynamic subscriber assignment from RADIUS accounting). For ISPs with DHCP/PPPoE subscriber management, the RADIUS integration provides the most accurate per-subscriber mapping.
Different subscriber classes get different thresholds. A residential customer with a 100 Mbps service plan has very different normal traffic patterns than a hosting customer with a 10 Gbps dedicated server. The absolute_bps_min field sets a floor below which Flowtriq will not trigger an alert, preventing false positives on low-traffic subscribers who occasionally burst.
Step 4: BGP FlowSpec Auto-Deployment
When Flowtriq detects an attack targeting a subscriber, it can automatically deploy BGP FlowSpec rules to your edge routers to filter the attack traffic. This is the surgical option that preserves legitimate traffic while dropping the malicious packets:
{
"mitigation": {
"provider": "exabgp_flowspec",
"adapter_socket": "/var/run/flowtriq/exabgp.sock",
"auto_deploy": {
"enabled": true,
"min_severity": "high",
"max_rules": 500,
"default_action": "rate-limit",
"rate_limit_bps": 50000000
},
"auto_withdraw": {
"enabled": true,
"below_threshold_seconds": 180
}
}
}
The max_rules field is important for ISPs. During a widespread attack campaign targeting many subscribers simultaneously, you do not want to deploy thousands of FlowSpec rules that overwhelm your routers' TCAM (hardware ACL table). The limit ensures Flowtriq prioritizes the most impactful rules. If the limit is reached, lower-severity incidents queue until slots become available.
For a detailed walkthrough of ExaBGP FlowSpec configuration, see our ExaBGP FlowSpec guide.
Step 5: RTBH as a Last Resort
BGP FlowSpec is the preferred mitigation because it preserves legitimate traffic. But there are scenarios where FlowSpec is not enough: massive volumetric floods that exceed your upstream capacity, attacks from millions of unique source IPs where FlowSpec rules cannot keep up, or hardware that does not support FlowSpec. In these cases, RTBH (Remote Triggered Black Hole) routing is the last resort.
RTBH works by announcing the target IP with a blackhole community to your upstream providers. They drop all traffic destined for that IP before it enters your network. The trade-off is severe: the subscriber loses all connectivity, but the rest of your network is protected.
{
"mitigation_fallback": {
"provider": "exabgp_rtbh",
"auto_deploy": {
"enabled": true,
"min_severity": "critical",
"trigger_conditions": {
"flowspec_ineffective_seconds": 60,
"bps_exceeds": 5000000000
}
},
"blackhole_community": "65001:666",
"auto_withdraw_seconds": 300
}
}
This configuration uses RTBH as an automatic fallback when FlowSpec rules are deployed but ineffective (attack traffic remains above threshold for 60 seconds) and the attack exceeds 5 Gbps. Flowtriq announces the target prefix with your blackhole community to your upstream peers.
Always configure RTBH with an auto-withdraw timer. A forgotten blackhole route leaves a subscriber permanently offline. Flowtriq's default is 300 seconds (5 minutes), after which it re-evaluates the attack and either re-announces or withdraws.
Step 6: Customer Notification
ISPs have an obligation (often contractual, sometimes regulatory) to notify customers when their services are affected by a DDoS attack. Flowtriq can automate this notification through configurable templates:
{
"customer_notification": {
"enabled": true,
"channels": ["email"],
"min_severity": "high",
"template": "ddos_attack_notification",
"include_details": {
"attack_vector": true,
"peak_volume": true,
"duration": true,
"mitigation_action": true,
"recommendations": true
},
"send_resolution_notice": true
}
}
The notification email includes a summary of the attack (vector, peak volume, duration) and recommendations the customer can take to reduce their exposure. For hosting customers, this might include enabling rate limiting or deploying a reverse proxy. For residential customers, it might include checking for compromised IoT devices on their network.
Flowtriq sends two emails per incident: one when the attack is detected and mitigation is activated, and one when the attack is resolved and mitigation is withdrawn. This gives the customer a complete record of the event for their own incident tracking.
Step 7: Compliance and Reporting
ISPs often need to produce DDoS reports for regulatory filings, insurance claims, or SLA documentation. Flowtriq maintains a complete audit trail of every incident, including:
- Detection timestamp: When the attack was first detected, with sub-second precision.
- Mitigation actions: Every FlowSpec rule deployed, every RTBH announcement, every notification sent.
- Traffic data: Per-second attack volume (pps and bps) for the entire incident duration.
- Resolution timestamp: When the attack ended and mitigation was withdrawn.
- Impact assessment: Which subscribers were affected and for how long.
Export incident reports in PDF or CSV format from the Flowtriq dashboard. For automated compliance reporting, use the Flowtriq API to pull incident data into your existing reporting pipeline.
SLA Tracking
If your customer contracts include SLA commitments around DDoS detection and mitigation times, Flowtriq tracks these metrics automatically:
- Time to detect (TTD): The interval between the start of attack traffic and Flowtriq's first alert. Typically under 30 seconds with sFlow at a 1:2048 sample rate.
- Time to mitigate (TTM): The interval between detection and the first mitigation action (FlowSpec rule deployment or RTBH announcement). Typically under 5 seconds for automated mitigation.
- Time to resolve (TTR): The total incident duration from first detection to confirmed resolution.
These metrics are available per-incident and as monthly aggregates in the Flowtriq dashboard.
Architecture: Putting It All Together
Here is the complete architecture for an ISP DDoS detection and mitigation deployment with Flowtriq:
- Edge routers export sFlow samples to the Flowtriq agent at each POP.
- Flowtriq agents analyze flow data in real-time, build per-subscriber baselines, and detect anomalies.
- Detection triggers send alerts to your NOC (via Slack, PagerDuty, or email) and initiate automated mitigation.
- ExaBGP receives FlowSpec rules from Flowtriq and announces them to edge routers via iBGP.
- Edge routers install FlowSpec rules as hardware ACLs, filtering attack traffic at line rate.
- If FlowSpec is insufficient, Flowtriq escalates to RTBH, announcing the target prefix with a blackhole community to upstream peers.
- Customer notification emails are sent automatically for high and critical incidents.
- Incident data is logged for compliance reporting and SLA tracking.
This entire pipeline runs automatically. Your NOC team receives alerts for awareness, but the detection, mitigation, and resolution cycle operates without human intervention. Manual override is always available through the Flowtriq dashboard for situations that require human judgment.
Tip: ISPs running Flowtriq alongside existing NMS tools (LibreNMS, Zabbix, PRTG) can export Flowtriq metrics to Prometheus and visualize them in the same Grafana dashboards as interface utilization, BGP session state, and other network health metrics.
Flowtriq is built for ISP-scale deployments, starting at $9.99/node/month with no bandwidth surcharges or per-attack fees. Whether you operate 5 edge routers or 500, pricing is predictable and scales linearly. Start your free trial to deploy flow-based DDoS detection across your network in under an hour.
Back to Blog