# Destination-Based RTBH (VRF CE-triggered)

**Topology**: ine-spv4

<figure><img src="/files/Bz1J8vmXArX8ie4HWAKE" alt=""><figcaption></figcaption></figure>

Load **rtbh.vrf.init.cfg**

```
#IOS-XE
config replace flash:rtbh.vrf.init.cfg
 
#IOS-XR
configure
load bootflash:rtbh.vrf.init.cfg
commit replace
y
```

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 <a href="#d816f757-42ca-4d46-980b-a8520dfccff2" id="d816f757-42ca-4d46-980b-a8520dfccff2"></a>

```
#R2, R4, R5 (PEs)
ip community-list standard RTBH permit 100:666
!
ip route 192.0.2.1 255.255.255.255 null 0
!
route-map IBGP_VPNV4_IN
 match community RTBH
 set ip next-hop 192.0.2.1
route-map IBGP_VPNV4_IN permit 20
!
route-map IBGP_VPNV6_IN
 match community RTBH
 set ipv6 next-hop ::ffff:192.0.2.1
route-map IBGP_VPNV6_IN permit 20
!
router bgp 100
 address-family vpnv4
  neighbor 3.3.3.3 send-community both
  neighbor 3.3.3.3 route-map IBGP_VPNV4_IN in
 address-family vpnv6
  neighbor 3.3.3.3 send-community both
  neighbor 3.3.3.3 route-map IBGP_VPNV6_IN in

#R3 (RR)
router bgp 100
 template peer-policy IBGP
  send-community both

#R2 (PE)
interface Loopback10
 vrf forwarding INET
 ip address 192.0.2.2 255.255.255.0
!
ipv6 route vrf INET 100::1/128 null 0
!
ip prefix-list PL_R1_RTBH_V4 permit 1.1.1.0/24 le 32
ipv6 prefix-list PL_R1_RTBH_V6 permit 2001:1::/32 le 128
!
route-map RM_R1_V4_IN permit 5
 match ip addr prefix-list PL_R1_RTBH_V4
 match community RTBH
 set community no-export additive
 set ip next-hop 192.0.2.1
!
route-map RM_R1_V6_IN permit 5
 match ipv6 addr prefix-list PL_R1_RTBH_V6
 match community RTBH
 set community no-export additive
 set ipv6 next-hop 100::1
 
#R1 (CE)
route-map RTBH
 set community 100:666
! 
router bgp 1
 address-family ipv4
  network 1.1.1.1 mask 255.255.255.255 route-map RTBH
  neighbor 10.1.2.2 send-community
 exit-address-family
 !
 address-family ipv6
  network 2001:1::1/128 route-map RTBH
  neighbor 2001:10:1:2::2 send-community

#XR1 (PE)
route-policy IBGP_VPN_IN
  if community matches-any (100:666) then
    set next-hop discard
  endif
  pass
end-policy
!
router bgp 100
 neighbor 3.3.3.3
  address-family vpnv4 unicast
   route-policy IBGP_VPN_IN in
  address-family vpnv6 unicast
   route-policy IBGP_VPN_IN in
!
route-policy RP_XR2_V4_IN
  if destination in (20.20.20.0/24 le 32) and community matches-any (100:666) then
    set community (no-export) additive
    set next-hop discard
  endif
  if destination in (20.20.20.0/24) then
    pass
  endif
end-policy
!
route-policy RP_XR2_V6_IN
  if destination in (2001:20::/32 le 128) and community matches-any (100:666) then
    set community (no-export) additive
    set next-hop discard
  endif
  if destination in (2001:20::/32) then
    pass
  endif
end-policy

#XR2 (CE)
route-policy RTBH
  set community (100:666)
end-policy
!
router bgp 20
 address-family ipv4 unicast
  network 20.20.20.20/32 route-policy RTBH
 !
 address-family ipv6 unicast
  network 2001:20::20/128 route-policy RTBH
 !
 neighbor 10.19.20.19
  address-family ipv4 unicast
   send-community-ebgp
 !
 neighbor 2001:10:19:20::19
  address-family ipv6 unicast
   send-community-ebgp
```

## Explanation <a href="#bc73073a-a6de-4e7e-9a9a-51d579bfabd4" id="bc73073a-a6de-4e7e-9a9a-51d579bfabd4"></a>

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:

1. The CE is allowed to blackhole this traffic (it owns the prefix)
2. 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.”

```
#R2, R4, R5
ip community-list standard RTBH permit 100:666
!
ip route 192.0.2.1 255.255.255.255 null 0
!
route-map IBGP_VPNV4_IN
 match community RTBH
 set ip next-hop 192.0.2.1
route-map IBGP_VPNV4_IN permit 20
!
route-map IBGP_VPNV6_IN
 match community RTBH
 set ipv6 next-hop ::ffff:192.0.2.1
route-map IBGP_VPNV6_IN permit 20
!
router bgp 100
 address-family vpnv4
  neighbor 3.3.3.3 route-map IBGP_VPNV4_IN in
 address-family vpnv6
  neighbor 3.3.3.3 route-map IBGP_VPNV6_IN in

#XR1
route-policy IBGP_VPN_IN
  if community matches-any (100:666) then
    set next-hop discard
  endif
  pass
end-policy
!
router bgp 100
 neighbor 3.3.3.3
  address-family vpnv4 unicast
   route-policy IBGP_VPN_IN in
  address-family vpnv6 unicast
   route-policy IBGP_VPN_IN in
```

Additionally, we must configure “send-community both” on the IOS-XE routers.

```
#R2, R4, R5
router bgp 100
 address-family vpnv4
  neighbor 3.3.3.3 send-community both
 address-family vpnv6
  neighbor 3.3.3.3 send-community both

#R3
router bgp 100
 template peer-policy IBGP
  send-community both
```

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:

```
route-policy RP_XR2_V4_IN
  if destination in (20.20.20.0/24 le 32) and community matches-any (100:666) then
    set community (no-export) additive
    set next-hop discard
  endif
  if destination in (20.20.20.0/24) then
    pass
  endif
end-policy
!
route-policy RP_XR2_V6_IN
  if destination in (2001:20::/32 le 128) and community matches-any (100:666) then
    set community (no-export) additive
    set next-hop discard
  endif
  if destination in (2001:20::/32) then
    pass
  endif
end-policy
```

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).

```
#R2
interface Loopback10
 vrf forwarding INET
 ip address 192.0.2.2 255.255.255.0
!
ipv6 route vrf INET 100::1/128 null 0
!
ip prefix-list PL_R1_RTBH_V4 permit 1.1.1.0/24 le 32
ipv6 prefix-list PL_R1_RTBH_V6 permit 2001:1::/32 le 128
!
route-map RM_R1_V4_IN permit 5
 match ip addr prefix-list PL_R1_RTBH_V4
 match community RTBH
 set community no-export additive
 set ip next-hop 192.0.2.1
!
route-map RM_R1_V6_IN permit 5
 match ipv6 addr prefix-list PL_R1_RTBH_V6
 match community RTBH
 set community no-export additive
 set ipv6 next-hop 100::1
```

All that’s left is for us to signal the prefixes from the CEs:

```
#R1
route-map RTBH
 set community 100:666
! 
router bgp 1
 address-family ipv4
  network 1.1.1.1 mask 255.255.255.255 route-map RTBH
  neighbor 10.1.2.2 send-community
 exit-address-family
 !
 address-family ipv6
  network 2001:1::1/128 route-map RTBH
  neighbor 2001:10:1:2::2 send-community

#XR2
route-policy RTBH
  set community (100:666)
end-policy
!
router bgp 20
 address-family ipv4 unicast
  network 20.20.20.20/32 route-policy RTBH
 !
 address-family ipv6 unicast
  network 2001:20::20/128 route-policy RTBH
 !
 neighbor 10.19.20.19
  address-family ipv4 unicast
   send-community-ebgp
 !
 neighbor 2001:10:19:20::19
  address-family ipv6 unicast
   send-community-ebgp
```

## Verification <a href="#fc1b08c7-8cdb-436a-bdb7-4903eb7f18d5" id="fc1b08c7-8cdb-436a-bdb7-4903eb7f18d5"></a>

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:

<div align="left"><figure><img src="/files/Vh1kemtuLao1TfdD5VhX" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/aC15Ro44nhex2TRtAFBO" alt=""><figcaption></figcaption></figure></div>

R2’s CEF table for the VRF should show that the IPv4 traffic is dumped out the dummy loopback, and IPv6 traffic is discarded:

<div align="left"><figure><img src="/files/v58f9b8qtJNROAzTWKZv" alt=""><figcaption></figcaption></figure></div>

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:

<div align="left"><figure><img src="/files/niWin7fdJIXRVKYhkbJB" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/C6FrZfdWVHXfjdiNkVKu" alt=""><figcaption></figcaption></figure></div>

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.

<div align="left"><figure><img src="/files/vh33Dz70c2rJlT8LGPuO" alt=""><figcaption></figcaption></figure></div>

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.

<div align="left"><figure><img src="/files/YoavxrIpm6oyPQkKVu6B" alt=""><figcaption></figcaption></figure></div>

On other PEs, such as R2, we can verify that these prefixes have a null0 nexthop as well:

<div align="left"><figure><img src="/files/z4cgkyVh5Xy8C1cmDb9e" alt=""><figcaption></figcaption></figure></div>

Traffic from any other PE destined for these four prefixes should be dropped at the edge. We can test this from R7:

<div align="left"><figure><img src="/files/rLNCSaFGtzz6OEmKK3B2" alt=""><figcaption></figcaption></figure></div>

Also ensure that other CEs do not see the host routes leaked from the provider (AS100):

<div align="left"><figure><img src="/files/ktBUGb4a4bObEE2RmOmB" alt=""><figcaption></figcaption></figure></div>

## A note on “regional” black holing <a href="#id-1bbd9041-084e-4106-a14b-0604c71b001e" id="id-1bbd9041-084e-4106-a14b-0604c71b001e"></a>

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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/bgp/destination-based-rtbh-vrf-ce-triggered.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.