Why does a BGP blackhole announced to only one of your two transits leave the flood arriving?

## BGP tells each neighbour something separately The mental model that produces this mistake is that a blackhole "marks an address as dead on the internet". It does not. A BGP speaker sends an announcement over a session to a specific neighbour, and each neighbour applies its own policy to what arrives. When you tag a more specific host route with the blackhole community and send it to transit A, you have asked **A** to install a discard route. Transit B was not asked, has no such route, and continues to resolve your address through your covering `/24` exactly as before. Its share of the flood keeps landing on your B-facing link. RFC 7999 reinforces this locality deliberately: it recommends the blackhole announcement carry `NO_EXPORT` (or `NO_ADVERTISE`) so that the discard does not leak onward into the wider internet from the AS you asked. That is a safety property, not a bug, but it means coverage is something you assemble one upstream at a time. ## The economics of a partial blackhole This is the part interviewers are actually probing. Attack traffic is destination routed, and the path it takes is chosen by each source's own network, not by you. So the flood arrives split, in whatever proportion the internet happens to route it. Blackholing at A removes A's share and does nothing to B's. If sixty percent came via A, your link relief is roughly sixty percent, and if your uplinks are still saturated by the remaining forty, you have gained nothing operationally. Meanwhile the cost landed in full the moment A honoured the request. Every user whose packets reached you via A now cannot reach that address at all. So a half-deployed blackhole is the worst cell in the table: **the complete outage, part of the relief**. If you are going to finish the denial for an address, do it everywhere at once, or do not do it. ## What has to be arranged in advance, per upstream Each transit has its own arrangements, and none of them are discoverable during an attack: | What differs per upstream | Why it bites you at 03:00 | |---|---| | The community value they honour | Some accept the well-known `65535:666`, others require a provider-specific community | | Longest prefix they accept | Their inbound filter normally rejects more specifics from you; the blackhole path is an explicit exception, often capped | | Whether they propagate it further | Some pass the discard to their own upstreams, some keep it local by design | | Automation or a phone call | A ticket-driven path can take longer than the attack lasts | The pattern to state in an interview: you announce a `/32` that your provider would normally filter, so this only works because someone made an exception for you in writing, on every session, and tested it on a quiet Tuesday with a harmless address. ## Prove the boundary actually denies An engineer who says "I announced it" has not answered the question of whether the packets stopped. Three checks, cheap and independent: - **Upstream route view.** Confirm each transit is actually carrying your more specific with the community intact, rather than silently filtering it. - **Your own interface counters.** Inbound bits per second on the link facing that transit should fall, and that is the number you actually care about. - **Reachability from outside.** The blackholed address should be unreachable from a source that transits each provider. Unreachable is the success criterion here, which is a strange thing to celebrate and worth saying plainly. ## The multi-homing twist worth knowing Because the covering prefix is still announced everywhere, the blackhole never affects your other addresses on either path. That is the design working: you have deaggregated one host out of your allocation for the purpose of killing it, and left the rest of the space routed normally. The risk in the other direction is an operator who reaches for the covering prefix instead, either because the automation defaulted there or because an upstream would not accept a longer one. That announcement is not a partial blackhole, it is a total one, and it takes every address you own off the internet on that path. ## What this means for the runbook The practical consequence is that "blackhole" is not one action but *n* actions, one per upstream, and they must fire together and be verified together. If your automation can only reach one provider, then your real mitigation capability is a fraction of what the runbook claims, and the honest thing to record is that number rather than the word.