BGP FlowSpec vs RTBH:
which mitigation method is right for your network

Back to Blog

What RTBH Actually Does

Remotely Triggered Black Hole (RTBH) routing is the oldest and most widely supported BGP-based DDoS mitigation technique. The concept is simple: when a destination IP is under attack, you announce that IP to your upstream provider with a special BGP community (typically 65535:666, the well-known blackhole community defined in RFC 7999). Every router that receives and honors that announcement drops all traffic destined for that IP before it enters your network.

The key word is all traffic. RTBH does not distinguish between attack packets and legitimate user requests. When you blackhole 198.51.100.10, every packet headed for that IP gets silently discarded at the provider edge. Your web server, API endpoint, or DNS resolver at that address becomes completely unreachable to the entire internet.

This is a deliberate trade-off. During a massive volumetric attack, the flood of traffic saturates your upstream links and degrades connectivity for every other IP on your network. RTBH sacrifices the targeted IP so the rest of your infrastructure survives. You are essentially doing the attacker's job for them on one IP to prevent them from taking down everything else.

RTBH propagation is fast. Because it uses standard BGP update messages with a community attribute, it works with nearly every BGP-speaking router on the planet. No special hardware, no firmware upgrades, no feature negotiations. If your provider peers with you over BGP and accepts the blackhole community, you can deploy RTBH in seconds.

There are two flavors of RTBH: destination-based (blackhole traffic to a target IP) and source-based (blackhole traffic from a source IP). Destination-based is far more common because spoofed source addresses make source-based RTBH unreliable for most DDoS scenarios.

What BGP FlowSpec Does

BGP FlowSpec (Flow Specification), defined in RFC 5575 and updated by RFC 8955, takes a fundamentally different approach. Instead of announcing a route with a blackhole community, FlowSpec distributes granular traffic filtering rules via BGP update messages. Each rule specifies match criteria and an action, turning every FlowSpec-capable router in the path into a distributed firewall.

FlowSpec match criteria go far beyond IP addresses. A single rule can match on any combination of:

• Destination IP prefix (e.g., 198.51.100.0/24)
• Source IP prefix (e.g., 203.0.113.0/24)
• IP protocol (TCP, UDP, ICMP, GRE, etc.)
• Source and/or destination port (e.g., source port 53, destination port 80)
• Packet length (e.g., packets larger than 512 bytes)
• TCP flags (e.g., SYN-only packets without ACK)
• DSCP value (Differentiated Services Code Point)
• Fragment bit (is-fragment, dont-fragment, first-fragment)
• ICMP type and code (e.g., echo-request only)

Once traffic matches a FlowSpec rule, the router applies one of several actions: drop the traffic (rate-limit to zero), rate-limit it to a specific bandwidth, redirect it to a VRF for scrubbing, or re-mark its DSCP value. This means you can write a rule that says "drop all UDP packets from source port 53, destined for 198.51.100.10/32, with a packet length greater than 512 bytes" and legitimate traffic to that same IP continues flowing normally.

The precision of FlowSpec is its primary advantage. During a DNS amplification attack, you do not need to take your DNS server offline. You filter only the amplified response packets while real DNS queries pass through untouched. During a SYN flood, you can drop SYN-only packets to a specific port while established TCP connections remain active.

Side-by-Side Comparison

The following table summarizes the key differences between RTBH and FlowSpec across the dimensions that matter most during an active DDoS attack:

Dimension            RTBH                          FlowSpec
─────────────────────────────────────────────────────────────────────────
Granularity          Per destination IP only        L3/L4 fields: src/dst IP,
                                                    protocol, port, length,
                                                    TCP flags, DSCP, fragment

Collateral damage    Total,  all traffic dropped     Minimal, only matching
                     to the target IP               flows are filtered

Propagation speed    Seconds (standard BGP update)  Seconds (standard BGP update)

Router support       Near-universal (any BGP        Limited to FlowSpec-capable
                     router + community support)    routers (see matrix below)

Configuration        Simple,  announce /32 with      Moderate, define match
complexity           blackhole community            criteria + action per rule

Max rules            1 per IP (the /32 announce)    Varies: 50-200 per provider,
                                                    limited by router TCAM

Layer coverage       L3 only (IP-level)             L3 + L4 (IP + transport)

Upstream filtering   Traffic dropped before it      Traffic filtered at the
                     reaches your link               FlowSpec-enforcing router

Use case             Volumetric floods that         Targeted attacks with
                     saturate your uplink           identifiable traffic signatures

RTBH Configuration Examples

RTBH configuration is straightforward across routing platforms. The core idea: announce the victim IP as a /32 with a next-hop pointing to a blackhole route, tagged with the blackhole community.

BIRD 2.x (Linux Router)

BIRD is the most common BGP daemon on Linux-based routers and route servers. Here is a minimal RTBH configuration:

# /etc/bird/bird.conf: RTBH blackhole injection

# Define a static blackhole route for the target IP
protocol static blackhole_routes {
    ipv4 { table master4; };

    # Blackhole target IP: add/remove entries during attacks
    route 198.51.100.10/32 blackhole {
        bgp_community.add((65535, 666));   # RFC 7999 well-known blackhole
        bgp_community.add((64500, 666));   # Provider-specific blackhole community
    };
}

# BGP session to upstream provider
protocol bgp upstream1 {
    local 10.0.0.2 as 65001;
    neighbor 10.0.0.1 as 64500;
    ipv4 {
        import none;
        export where (65535, 666) ~ bgp_community;
    };
}

FRRouting (FRR)

FRRouting is widely used on Linux-based network appliances and white-box switches:

# /etc/frr/frr.conf: RTBH with FRRouting

ip route 198.51.100.10/32 Null0 tag 666

route-map BLACKHOLE permit 10
  match tag 666
  set community 65535:666 64500:666
  set ip next-hop 192.0.2.1

router bgp 65001
  neighbor 10.0.0.1 remote-as 64500

  address-family ipv4 unicast
    redistribute static route-map BLACKHOLE
  exit-address-family

In both cases, adding or removing the static route triggers the BGP announcement. During an attack, you add the route; when the attack subsides, you remove it. The BGP withdrawal propagates upstream and traffic resumes.

FlowSpec Configuration Examples

FlowSpec configuration is more involved because you need to define precise match criteria. The most common approach for programmatic injection is ExaBGP, which lets external scripts push FlowSpec rules via a simple API.

ExaBGP: Drop a UDP Flood

# exabgp.conf: Drop UDP flood targeting 198.51.100.10 port 80
neighbor 10.0.0.1 {
    router-id 10.0.0.2;
    local-address 10.0.0.2;
    local-as 65001;
    peer-as 64500;

    flow {
        route drop-udp-flood {
            match {
                destination 198.51.100.10/32;
                protocol udp;
                destination-port =80;
            }
            then {
                rate-limit 0;
            }
        }
    }
}

ExaBGP: Filter DNS Amplification

# exabgp.conf: Filter DNS amplification (large UDP from port 53)
flow {
    route filter-dns-amp {
        match {
            destination 198.51.100.53/32;
            protocol udp;
            source-port =53;
            packet-length >512;
        }
        then {
            rate-limit 0;
        }
    }
}

ExaBGP: Rate-Limit NTP Amplification

# exabgp.conf: Rate-limit NTP monlist replies instead of dropping
flow {
    route ratelimit-ntp-amp {
        match {
            destination 198.51.100.0/24;
            protocol udp;
            source-port =123;
            packet-length >468;
        }
        then {
            rate-limit 12500;  # 100 Kbps in bytes/sec
        }
    }
}

BIRD 2.x: FlowSpec Rule

BIRD 2.x supports FlowSpec natively through its flow4 and flow6 channels:

# /etc/bird/bird.conf: FlowSpec via BIRD 2.x

flow4 table flowtab4;

protocol static flowspec_rules {
    flow4 { table flowtab4; };

    # Drop SYN flood to port 443
    route flow4 {
        dst 198.51.100.10/32;
        proto 6;          # TCP
        dport 443;
        tcp flags 0x02/0x12;  # SYN set, ACK not set
    }{
        bgp_ext_community.add((generic, 0x800600000000, 0));  # traffic-rate 0
    };
}

protocol bgp upstream_flowspec {
    local 10.0.0.2 as 65001;
    neighbor 10.0.0.1 as 64500;
    flow4 {
        table flowtab4;
        import none;
        export all;
    };
}

When RTBH Wins

Despite its blunt nature, RTBH remains the correct choice in several scenarios:

• Link saturation: When a volumetric attack exceeds your upstream link capacity (e.g., 400 Gbps hitting your 100 Gbps transit link), no amount of filtering at your router will help. The packets have already saturated the link before they reach your FlowSpec-capable router. RTBH signals your provider to drop traffic before it ever reaches your link, protecting the rest of your network.
• No FlowSpec support upstream: Many transit providers still do not accept FlowSpec announcements from customers. If your provider supports only blackhole communities, RTBH is your only BGP-based option for upstream filtering.
• Generic attack traffic: Some attacks use traffic that is indistinguishable from legitimate requests at L3/L4. HTTP floods from botnets using real browsers, randomized source ports, and standard TCP handshakes cannot be filtered by FlowSpec rules. If you cannot write a match rule that separates attack from legitimate, RTBH may be the only fast option.
• Expendable IPs: If the target IP hosts a service that can fail over to a different address (e.g., an anycast setup or a DNS record with a short TTL), blackholing the attacked IP while shifting traffic to a clean IP is a valid and fast response strategy.
• Simplicity under pressure: During a major incident with NOC staff under stress, RTBH is a one-line operation. There is no risk of writing a FlowSpec rule that accidentally matches legitimate traffic. You blackhole the IP, the flood stops, and you buy time to plan a more surgical response.

When FlowSpec Wins

FlowSpec is the superior choice when surgical precision matters more than raw capacity:

• Targeted protocol attacks: UDP floods, DNS amplification, NTP amplification, memcached reflection, and SSDP attacks all have distinct L3/L4 signatures. FlowSpec can match on protocol, port, and packet length to filter only the attack traffic.
• Critical IPs that cannot go offline: If the target IP hosts your primary DNS, API gateway, or e-commerce frontend, blackholing it causes an outage that may be worse than the attack itself. FlowSpec keeps the IP reachable for legitimate users.
• Attack volume within link capacity: If the attack is large but still within your upstream bandwidth, FlowSpec can filter it at the provider edge without any collateral damage. A 5 Gbps UDP flood on a 10 Gbps transit link is a perfect FlowSpec candidate.
• Multi-vector attacks with identifiable components: A blended attack might combine a UDP flood with a SYN flood and DNS amplification. FlowSpec lets you write separate rules for each vector, filtering them independently with different actions.
• Automated response pipelines: FlowSpec rules can be generated and injected programmatically via ExaBGP or GoBGP. This makes FlowSpec ideal for automated mitigation systems that detect an attack, classify it, and push filtering rules without human intervention.

The Escalation Model: FlowSpec First, RTBH as Fallback

The most effective DDoS mitigation strategy is not choosing one or the other. It is using both in a structured escalation chain. Start with the most precise tool available and escalate to blunter instruments only when precision fails.

Here is how a well-designed escalation model works in practice:

1. Detection: Your monitoring system identifies anomalous traffic patterns targeting a specific IP (PPS spike, bandwidth spike, protocol anomaly).
2. Classification: The system analyzes the attack traffic to identify its type, protocol, source characteristics, and distinguishing features.
3. FlowSpec deployment: If the attack has identifiable L3/L4 signatures, generate and inject FlowSpec rules to filter only the attack traffic. The target IP stays online for legitimate users.
4. Monitor effectiveness: Track whether the FlowSpec rules are reducing attack impact. If attack volume drops to manageable levels, the mitigation is working.
5. Escalate to RTBH if needed: If attack volume overwhelms the link despite FlowSpec filtering (because the attacker adapts, rotates vectors, or the volume simply exceeds capacity), escalate to RTBH blackholing. The target IP goes offline, but the rest of the network is protected.
6. De-escalate when safe: As the attack subsides, step back down: remove the blackhole, re-enable FlowSpec filtering, and eventually remove FlowSpec rules once traffic returns to baseline.

This escalation model gives you the best of both worlds. FlowSpec handles the majority of attacks without any collateral damage. RTBH serves as the safety net for the minority of attacks that exceed FlowSpec's capabilities.

The escalation thresholds matter. If you escalate to RTBH too aggressively, you will blackhole IPs unnecessarily. If you wait too long, a saturated link will cause collateral damage to other services. Tuning these thresholds based on your link capacity and traffic profile is critical.

Router and Platform Support Matrix

FlowSpec requires explicit support in the router's control plane and data plane. RTBH works on virtually any BGP router. Here is the current support landscape:

Platform              RTBH Support    FlowSpec Support    Notes
──────────────────────────────────────────────────────────────────────────────
Juniper MX Series     Full            Full (IPv4 + IPv6)  Best FlowSpec implementation;
                                                          all actions supported
Juniper SRX           Full            Full (IPv4)         Firewall-mode FlowSpec

Cisco IOS-XR          Full            Full (IPv4 + IPv6)  ASR 9000, NCS 5500/540;
(ASR/NCS)                                                 all actions supported
Cisco IOS-XE          Full            Partial (IPv4)      Limited actions; no VRF
                                                          redirect on most platforms

Nokia SR OS           Full            Full (IPv4 + IPv6)  7750 SR, 7950 XRS;
                                                          all actions supported
Arista EOS            Full            Partial (IPv4)      Basic drop/rate-limit;
                                                          improving in recent releases

BIRD 2.x              Full            Full (IPv4 + IPv6)  Linux-based; flow4/flow6
                                                          tables; widely used
FRRouting (FRR)       Full            Partial (client)    Receives FlowSpec; injection
                                                          improving; use ExaBGP to inject
ExaBGP                N/A             Full (controller)   Most popular FlowSpec injector;
                                                          no data plane
GoBGP                 N/A             Full (controller)   Go-based; gRPC API for
                                                          programmatic FlowSpec
OpenBGPD              Full            Limited             Minimal FlowSpec; not
                                                          recommended for production
MikroTik RouterOS     Full            None                No FlowSpec support;
                                                          RTBH via communities only

How Flowtriq Automates Both

Flowtriq's detection engine monitors traffic per-second across all your nodes. When an attack is detected, the classification engine identifies the attack type and determines whether it has filterable L3/L4 signatures. Based on that analysis, Flowtriq automatically selects and deploys the appropriate mitigation.

Automated FlowSpec Deployment

For attacks with identifiable signatures (UDP floods, amplification attacks, SYN floods, fragment floods), Flowtriq generates FlowSpec rules tailored to the specific attack characteristics and injects them via your configured BGP adapter (ExaBGP or GoBGP). The entire process takes seconds:

1. Flowtriq detects the attack (1-2 seconds via per-second PPS/BPS monitoring).
2. The classifier identifies the attack vector and extracts match criteria (protocol, ports, packet length patterns, TCP flags).
3. FlowSpec rules are generated and pushed to your BGP adapter.
4. The adapter announces the FlowSpec rules to your upstream routers.
5. Attack traffic is filtered at the network edge. Legitimate traffic continues flowing.

Automatic Escalation to RTBH

If FlowSpec rules are deployed but the attack continues to degrade the target (because volume exceeds link capacity, the attacker rotates vectors, or the traffic is too generic to filter), Flowtriq automatically escalates to RTBH. It announces the target IP with the configured blackhole community, and traffic is dropped at the provider edge.

Automatic De-escalation

When attack traffic subsides, Flowtriq steps back down the escalation chain. It removes the RTBH announcement first (restoring reachability), then monitors for a configurable cooldown period with FlowSpec still active, and finally withdraws the FlowSpec rules once traffic returns to baseline. Every action is logged in the audit trail with timestamps and traffic snapshots.

The escalation thresholds, cooldown timers, and actions are all configurable through the Flowtriq dashboard under Mitigation > Auto-Escalation. You can also set certain IPs to skip RTBH entirely (critical infrastructure that should never be blackholed) or require manual approval before escalating past FlowSpec.

Choosing the Right Strategy for Your Network

The right mitigation strategy depends on your infrastructure, your upstream providers, and the types of attacks you face. Here is a decision framework:

• Single-homed with one transit provider that supports only RTBH: Deploy RTBH as your primary mitigation. Supplement with host-level iptables/nftables for smaller attacks. Consider adding a scrubbing service for critical IPs.
• Multi-homed with FlowSpec-capable transit: Deploy FlowSpec as your primary mitigation with RTBH as the escalation fallback. This gives you surgical filtering for most attacks and a safety net for the rest.
• ISP or hosting provider with your own edge routers: Run FlowSpec on your own edge routers (BIRD or FRR) and also negotiate FlowSpec acceptance with your upstream providers. This gives you two layers of FlowSpec filtering.
• Anycast infrastructure: FlowSpec and RTBH both work well with anycast. You can blackhole or FlowSpec-filter at specific PoPs while other PoPs continue serving traffic normally.

Regardless of your setup, the best approach is to have both tools ready before you need them. Configure your RTBH communities, test your FlowSpec rules, verify provider acceptance, and automate the deployment pipeline. During an active attack is the worst time to debug BGP configuration.

Back to Blog

Related Articles