BGP-triggered blackholing
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.
- global
- 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 10.0.12.147 255.255.255.255 10.0.31.254- border
- 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 10.0.12.147 255.255.255.255 10.0.0.13 tag 65199- upstream
- 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 10.0.12.148 255.255.255.255 10.0.0.13 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.
Preliminaries
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 10.0.31.254 255.255.255.255 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 10.0.31.254 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 10.1.0.1 remote-as 65000 address-family ipv4 neighbor 10.1.0.1 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 match community BLACKHOLE-LEVEL3 CUSTOMER 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 10.10.0.1 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 10.0.12.147 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 10.10.0.1 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 10.10.0.1 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.
References
- Barry Raveendran Greene, Cisco Remote Triggering Black Hole Filtering
- Joe Soricelli, Juniper, and Wayne Gustavus, Verizon Options for Blackhole and Discard Routing
- Barry Raveendran Greene, Cisco, and Danny McPherson, Arbor Networks Sink Holes
- Chris Morrow and Brian Gemberling, UUNET How to Allow your Customers to blackhole their own traffic