Destination-Based RTBH (VRF CE-triggered)
Topology: ine-spv4
Load rtbh.vrf.init.cfg
R1, XR2, R7 and R8 are all dual-stacked internet peers in an INET VRF. Configure destination-based RTBH within the core so that traffic destined for 1.1.1.1/32, 20.20.20.20/32, 2001:1::1/128 and 2001:20::20/128 is dropped. Use the CEs (R1 and XR2) for signaling via BGP communities. On the PEs (R2, XR1) ensure that these CEs can only blackhole traffic for prefixes they own.
Answer
Explanation
This lab is a bit more realistic, in which a CE is allowed to tag traffic it wants to blackhole with <ASN>:666. The provider will match this tag and blackhole traffic for these prefixes. We must ensure two things:
The CE is allowed to blackhole this traffic (it owns the prefix)
The route advertisement does not leak beyond the provider.
First, we configure the RTBH communities and route-maps on the PEs as seen in the previous lab. IOS-XE requires the dummy null0 route, while XR1 is able to simply use “set next-hop discard.”
Additionally, we must configure “send-community both” on the IOS-XE routers.
Next, we have the PE policies which match 100:666, add the no-export community, and ensure that only prefixes owned by the CE are allowed to be blackholed. This is done more easily on IOS-XR, which is shown first. We simply add another if statement which matches prefixes in R2’s space up to /32 or /128, plus the community, adds no-export, and sets next-hop to discard:
On IOS-XE this is a bit more difficult. First, we must recurse the next-hop to a null0 route. Previously, this was done using a dummy null0 route in the global table. However, now the route is being learned directly from the CE in the INET VRF, so we need to recurse this to a null0 route in the INET VRF. Interestingly, this works fine for IPv6 but not IPv4. It seems that the null0 route for IPv4 makes the route inaccessible. To work around this, it seems if 192.0.2.1 is locally connected, it works fine. All we need is for R2 to direct traffic locally on the box and discard it. The most important thing is that R2 does not send this traffic to R1. Additionally, we add a higher-level route-map sequence which matches R1’s prefix space, up to a host route (/32 or /128), matches 100:666, adds no-export, and sets next-hop to a route that will recurse to null0 (or our dummy loopback).
All that’s left is for us to signal the prefixes from the CEs:
Verification
On R2, we should see the blackhole advertisements from R1 have no-export added, and the nexthop has been set to the dummy null0 route:
R2’s CEF table for the VRF should show that the IPv4 traffic is dumped out the dummy loopback, and IPv6 traffic is discarded:
There is actually a problem here. R2 seems to be using the link-local nexthop found on the route, and ignoring the 100::1 nexthop. I cannot find a way to work around this problem.
Let’s move on and check that R5 and XR1 are dropping this traffic:
Let’s now verify that XR1 is locally dropping traffic that XR2 signaled to be blackholed. This is much more straightforward on IOS-XR, thanks to the “set next-hop discard” command available on the route-policy.
We can also see on IOS-XR that these routes are marked with an N in the BGP RIB, signifying that they are discard routes.
On other PEs, such as R2, we can verify that these prefixes have a null0 nexthop as well:
Traffic from any other PE destined for these four prefixes should be dropped at the edge. We can test this from R7:
Also ensure that other CEs do not see the host routes leaked from the provider (AS100):
A note on “regional” black holing
This document mentions “regional black holing”:
https://sec.cloudapps.cisco.com/security/center/resources/ipv6_remotely_triggered_black_hole
The idea is fairly simple. Different regions of the provider network will match different BGP communities for blackholing. For example, the west coast might match <ASN>:6661, and the east coast might match <ASN>:6662. Therefore you can use these two communities to only cause blackholing within those regions. This gives you a bit more control over the drop process. All routers could also match a community such as <ASN>:6666 which could be used to drop at all regions at once.
Last updated