BGP-triggered blackholing

IOS recipes to implement blackholing in your network.
by Marco d'Itri
Did you really like this tutorial?
Buy me a book then! :-)

After designing the configuration to manage blackholing of local and customer addresses in my network, I took some time to document how it works in the hope that it will be useful to other people.

This document explains how to configure your routers to drop traffic sent to specific addresses by configuring special routes on one or more control routers.

Nothing here is very original, some other documents about this topic are listed in the references section.

Where to blackhole?

We distinguish three types of blackholing by their scope and we list the command which can be used on the control router to trigger them.

Packets are blocked everywhere in your network.
A route with the next-hop set to the sinkhole address is injected in iBGP. All routers then will drop the traffic directed to the target IP.
ip route
Packets are blocked at your border routers.
A normal route with the correct next-hop, but marked with a community which will cause it to be transformed in a blackhole route by the border routers.
ip route tag 65199
Packets are blocked by your transit providers before they enter your network.
Again a normal route with the correct next-hop, but marked with the communities used to signal to your transit providers that it is a blackhole route.
ip route tag 65198

The tag parameter is a route attribute internal to the router which can be used later in route-maps to select specifically tagged routes.

You may also choose to have independently configurable blackholing at the transit and peering routers.

If uRPF filtering is enabled on customer interfaces then globally blackholing a customer address will also have the effect of blocking packets sent from that IP.


First you need to choose the sinkhole IP address which will be used as the next-hop for the blackholed routes. It will be statically routed to the Null0 interface on every router on which traffic needs to be dropped:

ip route Null0

Advanced users may also use an IP address assigned to a computer configured to collect and analyze the intercepted packets.

The controlling routers

You need to configure one or more routers with the route-maps used to inject the static routes in BGP with the proper tags and next-hops. The first step is to enable redistributtion of static routes in BGP after filtering them with a route-map:

router bgp 65000
 redistribute static route-map STATIC-TO-BGP

And then you need a route-map entry for each type of blackholing.

Border blackholing inside your network works by applying to the blackhole route a community 65000:65199. The interested routers will use it to know that the next-hop of the route needs to be changed to the sinkhole address while the others will keep forwarding traffic to the destination as usual:

route-map STATIC-TO-BGP permit 10
 description border blackholing
 match ip address prefix-list host-routes-only
 match tag 65199
 set origin igp
 set community no-export 65000:65199

The routes which trigger internal blackholing lack the usual community used to tag customer routes and/or have the no-export community, so they will not be announced upstream or to customers.

Remote blackholing by the transit providers uses routes with the normal next-hop but tagged with the communities used to request blackholing on their side (in this example, Level3 and Sprint). The outgoing route-maps for these neighbors need to be modified to accept these routes as explained later.

route-map STATIC-TO-BGP permit 50
 description upstreams blackholing
 match ip address prefix-list host-routes-only
 match tag 65198
 set origin igp
 set community no-export 3356:9999 1239:66

Only accepting host routes is a precaution against typos when setting the static routes.

The controlling routers should be well protected from DoS attacks, or when attacked you will have no way left to stop the attack.

Border routers

The routers on which traffic will be conditionally dropped need to change the next-hop of blackhole routes to the sinkhole. The blackhole routes will be recognized by looking for the relevant community:

route-map CORE-IN permit 50
 description border blackholing
 match community BLACKHOLE
 set ip next-hop
route-map CORE-IN permit 10000

ip community-list standard BLACKHOLE permit 65000:65199

This route map should be applied to the routes received from the route reflectors or the controlling routers:

router bgp 65000
 neighbor remote-as 65000
 address-family ipv4
 neighbor route-map CORE-IN in

Transit border routers

The routes which trigger remote blackholing by the transit ISPs need to be recognized and accepted in the relevant outbound route-maps by checking for the blackholing community:

route-map AS3356-OUT permit 5
 description request blackholing

ip community-list standard BLACKHOLE-LEVEL3 permit 3356:9999

Since the route was tagged with the no-export community too, it needs to be accepted before no-export is checked.

Customer-triggered blackholing

You can allow your customers to remotely blackhole addresses on their networks by adding to their incoming route-map an entry which changes to the sinkhole address the next-hop for routes tagged with a specific BGP community:

router bgp 65000
 address-family ipv4
 neighbor route-map CUSTOMER-IN in

route-map CUSTOMER-IN permit 5
 match ip address prefix-list accept-only-32-from-customer-prefixes
 match ip community 65000:666
 set ip next-hop
 set community no-export

The continue statement would be useful here to remove the need for the modified prefix-list, but only very recent IOS releases support it for incoming route-maps.

The customer session needs a special configuration to allow IOS to accept a route with a next-hop which is not directly connected:

router bgp 65000
 neighbor disable-connected-check

If the disable-connected-check directive is not supported by the IOS release in use, then the session must be configured to use multihop BGP:

router bgp 65000
 neighbor ebgp multi-hop 2

Similar route-maps can be used to trigger border blackholing, by using the normal next-hop and applying the appropriate community.


  1. Barry Raveendran Greene, Cisco Remote Triggering Black Hole Filtering
  2. Joe Soricelli, Juniper, and Wayne Gustavus, Verizon Options for Blackhole and Discard Routing
  3. Barry Raveendran Greene, Cisco, and Danny McPherson, Arbor Networks Sink Holes
  4. Chris Morrow and Brian Gemberling, UUNET How to Allow your Customers to blackhole their own traffic