BGP RTBH: Stopping DDoS Traffic Before It Reaches You

When a volumetric DDoS attack lands on your network, the worst part usually isn’t what’s happening at the target IP. It’s everything else going down with it. Your upstream link is saturated, collateral traffic is getting dropped, and the services that have nothing to do with the attack are suffering just the same. Scrubbing centers and rate limits help, but they’re all downstream solutions. By the time traffic reaches them, it’s already consumed your pipe. What you actually want is for that traffic to disappear before it gets anywhere near you, and that’s exactly what BGP RTBH is designed to do.

RTBH, or Remotely Triggered Black Hole routing, is a technique described in RFC 5635 that lets you signal your upstream provider via BGP to null-route traffic destined for a specific IP or prefix at their edge, before it ever traverses the link between you. The mechanism is elegant in its simplicity: you advertise a BGP route for the IP under attack, tag it with a specific BGP community your provider recognizes as a blackhole signal, and their network starts dropping all traffic toward that destination at their routers. The attack traffic never makes it to you.

How the community signaling works

BGP communities are just 32-bit values attached to a route advertisement as an attribute, formatted in the familiar ASN:value notation. They’re typically used to influence routing policy, things like controlling which routes get re-advertised to other peers or adjusting local preference. In the RTBH case, providers designate a specific community value that means “null-route this prefix at our edge.” When your BGP session with the provider sees a route tagged with that community, their routers install a route for that prefix pointing to Null0 instead of your direction. Traffic arrives at their network, matches the route, and gets silently dropped.

Using AT&T as a real example: AT&T’s network runs under AS7018, and their designated RTBH community is 7018:86. If you peer with AT&T via BGP and you’re under attack, you can advertise the targeted prefix to them with community 7018:86 attached, and their network will begin blackholing all traffic toward it across their infrastructure. There are a few restrictions worth knowing about before you rely on this in production. AT&T will only honor the community on IPv4 prefixes between /25 and /32 in length. Anything at /24 or shorter gets rejected. On the IPv6 side, they accept /49 through /128. They also enforce that the prefixes you’re blackholing belong to your address space, not someone else’s, so this isn’t something that can be weaponized to drop someone else’s traffic.

In practice, most operators blackhole at the /32 level, isolating a single host under attack rather than an entire subnet. That keeps the blast radius as narrow as possible.

What this looks like on the router

On an Arista switch, the implementation is straightforward. You create a route-map that matches the prefix you want to blackhole and attaches the community, then apply it outbound on your BGP session toward AT&T. Something along these lines:

ip community-list RTBH permit 7018:86

route-map BLACKHOLE-TO-ATT permit 10
   match ip address prefix-list VICTIM-PREFIX
   set community 7018:86
!
route-map BLACKHOLE-TO-ATT permit 20
   description Permit all other prefixes — without this, everything else gets dropped
!

router bgp 65000
   neighbor 192.0.2.1 remote-as 7018
   neighbor 192.0.2.1 route-map BLACKHOLE-TO-ATT out
!

The prefix list VICTIM-PREFIX contains the specific /32 or subnet you’re signaling for blackholing. Once that advertisement propagates into AT&T’s network, their edge routers pick it up and install the Null0 route. Propagation is typically fast, within a few minutes at most, because BGP is already running and it’s just a new route being distributed.

Withdrawing the blackhole is just as simple: you pull the prefix from your advertisement, AT&T’s routers withdraw the Null0 route, and traffic starts flowing normally again. Most operators script this so they can trigger and clear a blackhole in seconds rather than manually touching router configs during an active attack.

The tradeoff you have to be honest about

There’s a real conversation that needs to happen internally before you use RTBH operationally, because it has a meaningful downside. When you blackhole a prefix, you’re not just stopping the attack traffic. You’re stopping all traffic toward that IP, including legitimate traffic from real users trying to reach your service. In that sense, RTBH completes the denial of service the attacker started. The target is still unreachable, just unreachable via a Null0 route at AT&T’s edge instead of via congestion at your link.

AT&T’s own documentation is upfront about this, describing RTBH explicitly as a traffic discard service and not a scrubbing service. If you want the attack traffic dropped while legitimate traffic continues flowing, that’s a scrubbing center or anycast-based DDoS mitigation product, not RTBH.

Where RTBH genuinely shines is when the alternative is worse. If the attack is volumetric enough to saturate your upstream link entirely, you’re already in a situation where nothing is getting through. In that case, blackholing the targeted prefix protects the rest of your address space and your link capacity. The targeted IP is still effectively down, but at least nothing else is collateral damage. For operators running multiple services on separate IPs, being able to surgically sacrifice one address to protect everything else is often exactly the right call.

It’s a blunt instrument, used correctly in the right situation, but a blunt instrument that works reliably and requires nothing more than a route advertisement to trigger.