How Flowtriq and Magic Transit Work Together
Cloudflare Magic Transit provides network-layer DDoS scrubbing by routing your IP prefixes through Cloudflare's global network. When traffic is diverted, Cloudflare inspects every packet, drops the malicious ones, and forwards clean traffic back to your origin through GRE or IPsec tunnels. It is one of the most effective scrubbing solutions available for volumetric attacks.
The challenge is knowing when to divert. Many teams run Magic Transit in "always-on" mode, which adds latency to every packet even during peacetime. Others rely on manual activation, which introduces human delay during an attack. Flowtriq solves this by providing the detection layer that Magic Transit lacks on its own: real-time, per-IP traffic analysis at your network edge that automatically triggers diversion through the Cloudflare API when attack thresholds are breached.
The integration works at two distinct layers. Flowtriq operates at Layer 3/4, analyzing flow data (sFlow, NetFlow, IPFIX) from your routers and switches to detect volumetric and protocol-level attacks. Magic Transit operates at the network routing layer, using BGP to attract traffic to Cloudflare's scrubbing centers. Flowtriq acts as the brain; Magic Transit acts as the muscle.
Prerequisites
Before configuring this integration, you need:
- An active Cloudflare Magic Transit subscription with your IP prefixes onboarded
- A Cloudflare API token with
Magic Transit Prefixread/write permissions - At least one Flowtriq agent deployed and detecting traffic on your network
- GRE or IPsec tunnels configured between your origin and Cloudflare (for on-demand mode)
If you are already running Magic Transit in always-on mode, this integration is still useful for triggering additional response actions (Slack alerts, runbook execution, incident logging) based on Flowtriq's more granular detection. However, the primary use case is on-demand mode where Flowtriq triggers the diversion automatically.
Step 1: Create a Cloudflare API Token
Navigate to the Cloudflare dashboard, go to My Profile > API Tokens, and create a custom token with the following permissions:
- Account > Magic Transit Prefixes > Edit
- Account > Magic Transit Prefixes > Read
Restrict the token to the specific account that owns your Magic Transit configuration. Copy the token value. You will need it in the next step.
Use a dedicated API token for Flowtriq rather than your global API key. This follows the principle of least privilege and makes it easy to revoke access without affecting other integrations.
Step 2: Configure the Magic Transit Integration in Flowtriq
In the Flowtriq dashboard, navigate to Settings > Mitigations and click Add Mitigation Provider. Select "Cloudflare Magic Transit" and fill in the configuration:
{
"provider": "cloudflare_magic_transit",
"name": "Cloudflare MT - Production",
"api_token": "your-cloudflare-api-token",
"account_id": "your-cloudflare-account-id",
"prefixes": [
{
"prefix": "203.0.113.0/24",
"description": "Production subnet",
"auto_advertise": true
},
{
"prefix": "198.51.100.0/24",
"description": "Customer subnet",
"auto_advertise": true
}
]
}
The auto_advertise field controls whether Flowtriq can automatically trigger BGP advertisement for that prefix through the Cloudflare API. Set this to true for prefixes you want protected automatically. Set it to false for prefixes where you want manual confirmation before diverting.
Step 3: Configure Auto-Divert Thresholds
Thresholds determine when Flowtriq tells Cloudflare to start advertising your prefix (diverting traffic for scrubbing). You can set thresholds based on packets per second, bits per second, or both:
{
"auto_divert": {
"enabled": true,
"conditions": {
"bps_threshold": 500000000,
"pps_threshold": 200000,
"operator": "OR",
"sustained_seconds": 30
},
"cooldown_minutes": 10,
"max_divert_duration_minutes": 120
}
}
Let us break down each field:
bps_threshold: Trigger diversion when attack traffic exceeds 500 Mbps. Set this below your circuit capacity to ensure diversion happens before saturation.pps_threshold: Trigger diversion when attack packets exceed 200,000 per second. This catches packet-flood attacks that may not be high bandwidth but still overwhelm forwarding hardware.operator: "OR" means either threshold triggers diversion. Use "AND" if you want both conditions met simultaneously (more conservative).sustained_seconds: The attack must exceed the threshold for 30 continuous seconds before diversion is triggered. This prevents brief traffic spikes from causing unnecessary diversions.cooldown_minutes: After withdrawing a prefix advertisement, wait at least 10 minutes before re-diverting. This prevents flapping if an attack stops and restarts.max_divert_duration_minutes: Automatically withdraw the advertisement after 120 minutes even if the attack is still ongoing. This is a safety net to prevent forgotten diversions from adding permanent latency.
Choosing the Right Thresholds
The ideal threshold depends on your network capacity and normal traffic patterns. Here are guidelines based on common deployment scenarios:
- 1 Gbps circuit: Set
bps_thresholdto 400,000,000 (400 Mbps). This gives you a 60% headroom buffer. - 10 Gbps circuit: Set
bps_thresholdto 3,000,000,000 (3 Gbps). You have more headroom, so a higher threshold reduces unnecessary diversions. - 100 Gbps backbone: Set
bps_thresholdto 20,000,000,000 (20 Gbps). At this scale, smaller attacks are handled locally and only major volumetric events warrant scrubbing.
Start conservative (lower thresholds) and raise them over time as you observe normal traffic patterns and false positive rates in the Flowtriq dashboard.
Step 4: Auto-Withdraw on Resolution
When Flowtriq detects that the attack has ended, it can automatically withdraw the BGP advertisement, returning traffic to the direct path without Cloudflare scrubbing. This eliminates the latency overhead of scrubbing during peacetime.
{
"auto_withdraw": {
"enabled": true,
"conditions": {
"below_threshold_seconds": 120,
"require_incident_resolved": true
}
}
}
The below_threshold_seconds field requires attack traffic to be below the divert threshold for 120 continuous seconds before withdrawing. This prevents premature withdrawal if the attacker pauses briefly and resumes. The require_incident_resolved field adds an extra safety check: the Flowtriq incident must be in a "resolved" state before withdrawal occurs.
We recommend setting
below_threshold_secondsto at least 120 seconds. Attackers frequently stop for 30 to 60 seconds to test whether defenses have been lowered, then resume at full volume. A 2-minute window catches most of these restart patterns.
Step 5: Monitoring the Integration
Once configured, the Flowtriq dashboard shows a real-time view of Magic Transit diversion status for each prefix. You can see:
- Diversion state: Whether each prefix is currently being advertised (diverted) or withdrawn (direct).
- Diversion history: A timeline showing when diversions were triggered and withdrawn, including the trigger reason (threshold breach, manual override).
- Scrubbed traffic: Cloudflare's reported scrub rate, showing how much malicious traffic was dropped before reaching your network.
- Latency impact: The additional latency introduced by the scrubbing path, so you can quantify the cost of diversion.
All diversion events are also sent through your configured alert channels. If you have Slack or PagerDuty set up, your team will receive notifications when a prefix is diverted and when it is withdrawn.
Example: Complete Configuration
Here is a complete mitigation provider configuration that combines all the settings above into a single production-ready config:
{
"provider": "cloudflare_magic_transit",
"name": "Cloudflare MT - Production",
"api_token": "cf-api-token-here",
"account_id": "cf-account-id-here",
"prefixes": [
{
"prefix": "203.0.113.0/24",
"description": "Production",
"auto_advertise": true
}
],
"auto_divert": {
"enabled": true,
"conditions": {
"bps_threshold": 500000000,
"pps_threshold": 200000,
"operator": "OR",
"sustained_seconds": 30
},
"cooldown_minutes": 10,
"max_divert_duration_minutes": 120
},
"auto_withdraw": {
"enabled": true,
"conditions": {
"below_threshold_seconds": 120,
"require_incident_resolved": true
}
}
}
Troubleshooting
Diversion Not Triggering
If an attack exceeds your threshold but diversion does not activate, check the following:
- Verify the API token has write permissions for Magic Transit Prefixes.
- Confirm the prefix in Flowtriq matches exactly what is configured in Cloudflare (including the CIDR notation).
- Check that
auto_advertiseis set totruefor the prefix. - Review the Flowtriq event log for API error responses from Cloudflare.
Prefix Stuck in Diverted State
If a prefix remains diverted after the attack ends, check that auto_withdraw is enabled and that the incident has been resolved in Flowtriq. You can also manually withdraw a prefix from the Flowtriq dashboard or directly in the Cloudflare dashboard.
Flapping Between Divert and Withdraw
If a prefix repeatedly diverts and withdraws in short succession, increase the cooldown_minutes value and the below_threshold_seconds value. This is typically caused by an attacker who adjusts volume in response to the diversion.
Tip: For networks that also use BGP FlowSpec, combine Magic Transit for volumetric scrubbing with ExaBGP FlowSpec rules for surgical, protocol-level filtering. This layered approach handles both massive floods and targeted application-layer attacks.
Cloudflare Magic Transit integration is available on all Flowtriq plans starting at $9.99/node/month. The integration is included at no additional cost beyond your existing Magic Transit subscription. Start your free trial to connect Flowtriq's detection engine to Cloudflare's scrubbing network in minutes.
Back to Blog