In this post I'll describe a basic setup using Cisco IOS, IOS XR and exaBGP that will function as a BGP remotely triggered blackhole (RTBH) allowing you to null route any source/destination prefix. The example topology will be as below:
Unlike BIRD or Quagga, ExaBGP was not designed to transform a general purpose server into a router, but to allow engineers to control their BGP network easily. Think of it as Software Defined Networking for people with "commodity" routers.
Before we start just outline some functions/feature our design must consider:
- Must NULL route in our own ASN and automagically with upstream providers
- Must only allow /32 prefixes to be back holed
- Must do some basic sanity checking at each step
- Should allow us to blackhole both source and destination prefixes
Simply installed following the instructions from the exaBGP site then edit the exaBGP.conf file to two sessions configured for our example(IOS and IOS_XR routers from topology above). Note the static section as this is where we configure prefixes to announce with exaBGP.
So that's the sessions configured (obviously needs associated config on the routers) now the interesting bit lets add a single /32 to the exaBGP.conf file under the "static section":
There are all the normal BGP attributes available under exaBGP but as you will see below in this example we are only really going to use communities to do what we want :)
The config is pretty much the same for both IOS and XR its just the syntax thats different really. Both will accomplish the same thing. First off we need to add a null route for us to point to as a next-hop. For IPv4 there is a convention to use this "documentation" address but for IPv6 we have a nice 'official' address range to use :)
ip route 192.0.2.1 255.255.255.255 null0
ipv6 route 0100::/64 null0
Now we have somewhere we can set the next hop to. As part of the sanity checks we want to configure a prefix-list containing important IPs that we never want to be null routed or would be painful for us. Imagine null routing the loopbacks of your core routers? So lets configure one that contains the loopbacks of our cores, the exaBGP host IP and the IPs of our transit provider sessions:
Now we need to configure the blackhole community on the router to match against:
Next is a prefix list that will only match /32 prefixes:
Now we can create an import route-map to check what we want before accepting the announcement from exaBGP:
This route-map will make sure the prefix is not in the core-ipv4 list then only accepts if it is of /32 in length and has the blackhole community tagged on it. At this stage we can NULL route this /32 prefix within our own ASN! :D The next route-map should be added to your transit route-map. Its quite simple and just matches against the blackhole community then sets the transit provider specific RTBH community.
route-map transit-out premit XX description Blackhole upstream match community blackhole set community 65002:666
Now we will blackhole the prefix and ask our transit provider to do the same so we are never even sent the traffic!
This is very much the same as the IOS config so not much description here just the config snippets:
Add the routes:
Add the community:
The import policy from exaBGP:
Then we just need to add something similar to the following to our transit provider export rpl
What does this do?
So following the example topology from the top of the post. We can announce a prefix with exaBGP to all our core routers this prefix will only be accepted if it is tagged with the blackhole community, is a /32 and is NOT an IP from our "protected" list. This affords us some comfort that we cant null route our transit sessions or a core router loopback making BGP b0rk. The core routers will null route the prefix locally while adding appropriate upstream blackhole communities so we never even receive the traffic.
If you add uRPF into the config this will mean we can also blackhole traffic based on the source address! So if the DOS isnt particularly distributed we can mitigate it by blackholing the source IPs and keeping everyone a little happier.
So now we can do all this stuff imagine doing it in a more automatic fashion :) Analysing netflow output or output from an NFSEN plugin along with integration into exaBGP to add prefixes after a quick manual review or if your really brave automatically. Then look into flowspec and exaBGP :P