Automating RTBH: BGP Blackhole Communities Guide

Automating RTBH (remotely triggered blackhole) means your DDoS detector announces a /32 (or /128) for the attacked IP to your upstream with a blackhole BGP community, and withdraws it automatically when the attack is over. The upstream then drops all traffic to that address at its edge, so the flood never reaches your links.

RTBH is crude, but it is fast and nearly universal. This guide covers how it works, how to wire it up on common platforms, how to handle removal, and where it hurts you.

How RTBH works

1. Your detector sees an IP exceeding a bps or pps threshold in flow data.
2. It announces a host route for that IP to your router, usually over iBGP.
3. Your router re-announces the route to the upstream with the upstream's blackhole community, and often NO_EXPORT.
4. The upstream sets the next hop to a discard interface. Traffic toward that IP is dropped before it crosses your transit link.

The standardized community is BLACKHOLE = 65535:666 (RFC 7999). Many providers also define their own, such as <their-ASN>:666 or another value in their documentation. This article uses 64496:666 for a documentation-range upstream (AS64496). Always use the value your provider publishes.

The result is that the victim IP goes completely offline. You are trading one host's availability for the stability of everything else on the link. That is the core trade-off of RTBH.

Check upstream support first

Before you automate anything, confirm these points with each transit provider and IXP:

• Community: which blackhole community they accept, and whether they honor 65535:666.
• Prefix length: most providers filter IPv4 routes longer than /24, but make an exception for blackhole-tagged /32s. Confirm the same for IPv6 /128 (some use /64 or longer limits).
• Validation: whether they check that the prefix falls inside your IRR objects or your AS-SET. A blackhole for space you don't have registered will be rejected.
• Limits: the maximum number of blackhole prefixes per session.
• Scope: whether they support regional or per-peer blackhole communities, so you can limit the impact.
• Behavior: whether they drop traffic only at their edge or also re-advertise it to their peers (that is why NO_EXPORT matters).

Test with a spare IP in a maintenance window. Confirm the route is accepted and that traffic really stops, using traceroute from an outside looking glass.

Configuration examples

All examples use documentation addresses. Your own space is 192.0.2.0/24, your ASN is AS64500, and the upstream is AS64496.

Juniper (Junos): accept triggers from the detector, tag, and export

Your detector announces over iBGP with an internal trigger community, 64500:666. The edge router validates the route, rewrites the next hop to discard, and adds the upstream community.

set policy-options community RTBH-TRIGGER members 64500:666
set policy-options community UPSTREAM-BH members 64496:666
set policy-options community NO-EXPORT members no-export

set policy-options policy-statement FROM-DETECTOR term BH from route-filter 192.0.2.0/24 prefix-length-range /32-/32
set policy-options policy-statement FROM-DETECTOR term BH from community RTBH-TRIGGER
set policy-options policy-statement FROM-DETECTOR term BH then community add UPSTREAM-BH
set policy-options policy-statement FROM-DETECTOR term BH then community add NO-EXPORT
set policy-options policy-statement FROM-DETECTOR term BH then next-hop discard
set policy-options policy-statement FROM-DETECTOR term BH then accept
set policy-options policy-statement FROM-DETECTOR term DEFAULT then reject

set policy-options policy-statement TO-UPSTREAM term BH from community UPSTREAM-BH
set policy-options policy-statement TO-UPSTREAM term BH then accept

The route-filter line is the most important safety control. It stops a bad trigger from blackholing anything other than a single host in your own space.

Cisco IOS-XE: static null route redistributed with a tag

ip route 192.0.2.66 255.255.255.255 Null0 tag 666

route-map RTBH-OUT permit 10
 match tag 666
 set community 64496:666 no-export additive

router bgp 64500
 address-family ipv4
  redistribute static route-map RTBH-OUT
  neighbor 198.51.100.1 send-community

This works well for manual triggers. For automation, have your detector peer with the router and apply an inbound route-map equivalent to the Junos one above.

MikroTik RouterOS v7

/ip route add dst-address=192.0.2.66/32 blackhole comment="rtbh"

/routing filter rule add chain=upstream-out \
  rule="if (dst in 192.0.2.0/24 && dst-len == 32 && blackhole) { append bgp-communities 64496:666; accept }"

RouterOS filter syntax has changed between v7 releases. Verify it on your version in a lab first, and keep a final reject rule in the chain so that only intended routes leave.

Linux with BIRD 2 as the trigger speaker

If you want a simple host that announces routes to your router, a static route with communities is enough:

protocol static rtbh4 {
    ipv4;
    route 192.0.2.66/32 blackhole {
        bgp_community.add((64500,666));
    };
}

Add or remove the route line and run birdc configure. Detection tools usually do the same thing through ExaBGP, GoBGP, or a built-in BGP speaker.

Automatic removal: the hard part

Withdrawing is trickier than announcing. Once the upstream is dropping traffic to the IP, your flow data no longer shows the attack. You can't tell whether it has stopped. Practical approaches:

• Fixed expiry timer. Withdraw after a set time, for example 10-30 minutes, and let the detector re-trigger if the traffic returns.
• Exponential back-off. Make each re-trigger for the same IP last longer, such as 10, 20, 40 minutes, up to a cap.
• Hold-down before re-announce. Prevent flapping between withdraw and announce within a short window.
• Maximum duration with a human alert. If an IP stays blackholed for hours, notify someone instead of waiting silently.
• Upstream-side visibility. Some providers offer counters or portal data for blackholed traffic. Use them if they exist.

Whichever tool you use, check how it handles expiry, whether the state survives a restart, and what happens to announced routes if the detector dies. A detector that crashes after announcing and never withdraws can leave a customer offline for days.

Common mistakes and risks

• No prefix filter on the trigger session. One misconfigured script announcing 192.0.2.0/24 with the blackhole community takes your whole range down. Accept only host routes inside your own space.
• Forgetting NO_EXPORT. Without it, some upstreams may propagate the route further than you intended.
• Blackholing critical infrastructure. Your DNS resolvers, mail relays, and BGP peering addresses should be on an exclusion list. Don't let an automated action cut them off.
• Shared IPs. On a hosting platform, one blackholed IP can take down many tenants. Consider the customer mix before you set thresholds.
• Thresholds that are too tight. A flash crowd looks like an attack. Base thresholds on measured baselines (see our guide on NetFlow DDoS detection thresholds) and use both bps and pps.
• Not testing the withdraw path. Teams test the announcement but never check that removal clears the route on the upstream's side.
• Treating RTBH as protection. It finishes the attacker's job for that IP. It protects the rest of your network, not the victim.

When to move beyond RTBH

Use RTBH as a safety valve for volumetric floods that threaten your uplinks. For better granularity:

• BGP FlowSpec can drop or rate-limit by protocol, port, or packet size, so legitimate traffic to the victim still flows. This depends on whether your upstream accepts FlowSpec from you.
• Scrubbing. Redirecting traffic through a scrubbing service lets you keep the target online. NixGuard Edge does this for networks with their own ASN and at least one /24. Your prefixes are announced from the scrubbing edge, and clean traffic returns over a GRE tunnel with a BGP session inside. It can be used always-on or on demand.

Where NixMon fits

NixMon detects attacks from NetFlow v5/v9, IPFIX, or sFlow with per-IP and per-prefix bps/pps thresholds, and can respond with BGP blackhole (RTBH) or BGP FlowSpec announcements, an on-prem NixGuard firewall, or NixGuard Edge. You can test the full chain, from detection through BGP announcement to your router's policy, in the 15-day free trial. No credit card is needed. Run it first against a spare test IP before you rely on it for production.

Quick deployment checklist

1. Get the blackhole community, prefix length rules, and limits in writing from each upstream.
2. Build an inbound policy on the trigger session: own space only, /32 and /128 only, specific trigger community.
3. Add the upstream community and NO_EXPORT on export.
4. Create an exclusion list for critical IPs.
5. Set expiry timers and back-off, and alert on long-running blackholes.
6. Test announce, traffic drop, and withdraw end to end.
7. Define an escalation path to FlowSpec or scrubbing for repeat targets.