What does a BGP blackhole announcement for a flooded /32 stop, and what does it finish?
answer
- who drops the packets, and where
- the relief happens above your uplink
- the match is on destination, nothing else
- prefix length is the only dial
- you completed the denial for that address
basics
~20 sIt stops the flood from reaching your access link, because the upstream discards those packets inside its own network. It finishes the outage: every packet to that address is dropped, so legitimate users lose the service too.
solid answer
~50 sYou announce a more specific route, usually a single `/32`, to your transit provider tagged with a community that asks them to discard traffic for it; RFC 7999 standardised `65535:666` (BLACKHOLE) for this. The provider installs that route with a discard next hop, so the flood dies on their high-capacity edge and never enters your uplink. That saves the link, the border router, and every other service sharing the pipe. What it does not do is separate attack traffic from customers: routing matches destination address only, so the blackhole completes the denial for that address at every provider that honoured it. The honest way to say it in an interview is that you deliberately finished killing one address to save everything else on the link, and the whole judgement is whether that address was worth sacrificing.
code
text · 8 linesprefix : 203.0.113.45/32 <- one host inside our own /24
community : 65535:666 (BLACKHOLE), NO_EXPORT
next-hop : rewritten by the transit to a discard route
effect : every packet to 203.0.113.45 dropped at the transit's edge,
from every source, attacker and customer alike
...
prefix : 203.0.113.0/24 <- still announced, still reachable
next-hop : our border routergo deeper
Be ready to say in one breath what it saves and what it kills: the link survives, the announced address goes completely dark for everyone. Know that you are asking an upstream to discard, not filtering anything yourself.
Explain the mechanics: a more specific route tagged with the blackhole community, accepted by the upstream and installed with a discard next hop, propagating in seconds, matching destination address only. Know that prefix length is the only granularity available.
Show the judgement, not the mechanism. State what you are trading, name what else lives on that address before you announce it, and say what your withdrawal criterion is when the attacker can outlast you.
Own the framing that this control deliberately completes the denial, and decide in advance who is allowed to authorise it, for which addresses, and whether the organisation should buy a granular upstream alternative instead of living with the coarse one.
## What is actually being announced BGP is how autonomous systems tell each other which addresses they can reach. Normally you announce your allocation, say `203.0.113.0/24`, to each transit provider, and the internet delivers packets for those addresses to your border routers. A blackhole announcement inverts that for one destination. You announce a **more specific** route, typically a single host route (`/32` for IPv4, `/128` for IPv6), tagged with a community meaning "please discard traffic for this". RFC 7999 standardised the well-known value `65535:666` (BLACKHOLE) for exactly this purpose, and recommends the announcement also carry `NO_EXPORT` so it does not propagate beyond the AS you asked. When the upstream accepts it, it installs that route with a next hop pointing at a discard interface. Packets addressed to that host are dropped inside the provider's network, on their own edge, before they ever reach your access link. ## What that buys you The thing you are protecting is not the flooded service. It is **the link and everything behind it**. A volumetric flood larger than your uplink cannot be filtered by anything you own, because the saturation happens on the wire before your border router gets a vote. A packet filter at your edge sees only what survived the congestion, and drops it after the damage is done. The blackhole is the only lever that acts *upstream of the bottleneck*, which is precisely why the control is defined by asking somebody else to act. It is also fast. The announcement propagates through the provider's internal BGP in seconds, which is why it is the lever an on-call engineer reaches for at 03:00. Relief arrives before most people have finished reading the alert. ## What it finishes Routing matches on destination address, and on nothing else. No part of this announcement can tell a flood packet from a paying customer's packet. Everything addressed to that host dies: the attacker's traffic and every legitimate request, from every source, at every provider that honoured the request. The attacker's objective was that the service be unreachable. The blackhole achieves that objective, in seconds, more completely and more reliably than the flood itself was managing. This is not a paradox to hide in an interview; it is the whole point of the control. You trade one address for the link. It is the right trade when the flooded address carries something you can afford to lose and the link carries things you cannot. It is the wrong trade when the flooded address *is* the business, and saying so out loud is what separates a candidate who understands the tool from one who has memorised its name. ## Granularity is the only dial The prefix length is your blast radius, and it is the only knob the mechanism gives you. A `/32` kills one address. A `/24` kills two hundred and fifty six. Providers normally filter more specifics from customers so you cannot accidentally announce someone else's space or deaggregate the table, so accepting a `/32` from you is an explicit exception in their inbound policy, arranged in advance and usually capped at a maximum length. If that arrangement does not exist before the attack, you spend the outage on a phone call. What the dial cannot do is express "drop UDP port 53 from this size range and leave the rest alone". That granularity requires a rule the upstream installs on your behalf, which BGP Flowspec can carry: it matches protocol, source and destination ports, packet length and more, and can rate limit rather than discard. It needs an upstream that offers it, a session set up beforehand, and normally a validation that the destination you are filtering falls inside a prefix you already originate to them. Very few organisations negotiate that into a transit contract before their first flood, which is why the coarse lever is the one actually on the desk during the incident. ## Getting back Withdrawing the announcement restores reachability as fast as it removed it, in seconds. But the clock belongs to the attacker as much as to you: they can stop, wait for the route to come back, and start again, so a withdrawal is a decision to re-test the flood, not a declaration of victory. If instead you move the service to a fresh address, your recovery time is set by the cached DNS TTL of the old name, not by BGP convergence, and an attacker who resolves the new name follows you there. ## The sentence to have ready "A blackhole is not mitigation. It is a controlled, upstream, self-inflicted outage of one destination, bought in exchange for the survival of the link." Everything else on this subject is a consequence of that sentence.
- Why announce a /32 rather than your whole /24?Because prefix length is the blast radius. A `/24` takes every address in it offline, including services that were never touched. The `/32` confines the self-inflicted outage to the single flooded host. The catch is that providers normally filter more specifics from customers, so accepting a `/32` from you is a pre-arranged exception in their inbound policy, often with a maximum length they will honour. If nobody negotiated it, you discover it mid-incident.
- How do you get the service back once the flood stops?Withdraw the announcement; reachability returns in seconds, as fast as it went away. But that is a test, not a victory: the attacker can be watching and simply restart, so the withdrawal needs a criterion and someone willing to re-announce. If you instead renumber the service onto a fresh address, your recovery clock is the cached DNS TTL of the old name, not BGP convergence.
- Why can a firewall or ACL at your own border not do this job?Because the congestion is upstream of it. When the flood exceeds your access link, packets are already being dropped on the wire, indiscriminately, before your border router sees them. Your filter can drop the survivors perfectly and the link stays full. Any effective answer to a volumetric flood has to act on the far side of the bottleneck, which means asking an upstream.
It is the flood barrier a town builds by demolishing the one house the river is pouring through. The street stays dry and the house is gone, on purpose.
saying these in an interview costs you the question
- Calls blackholing mitigation, as if users keep the service
- Thinks the announcement drops only the attacker's packets
- Believes a border ACL can handle a link-saturating flood
- Assumes the provider inspects payload to decide what to discard
- Forgets that prefix length decides how much goes dark