# Destination-Based RTBH (VRF Provider-triggered)

**Topology**: ine-spv4

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FCpJzIe28sxS1jHnwsTgT%2Fimage.png?alt=media&#x26;token=3af68d72-0a86-4b5c-bd23-7a42c2657c36" 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 and 2001:1::1/128 is dropped. Use R4 as the signaling server, using communities for triggering the RTBH.

## Answer <a href="#bdd66675-ed16-4dd6-8835-a2e1c8435d81" id="bdd66675-ed16-4dd6-8835-a2e1c8435d81"></a>

```
#R2, R4, R5 (PEs)
ip community-list standard RTBH permit 100:666
!
ip route 192.0.2.1 255.255.255.255 null0
!
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
 add vpnv4
  neighbor 3.3.3.3 route-map IBGP_VPNV4_IN in
  neighbor 3.3.3.3 send-community both
 add vpnv6
  neighbor 3.3.3.3 route-map IBGP_VPNV6_IN in
  neighbor 3.3.3.3 send-community both

#R4 (Trigger router)
ip route vrf INET 1.1.1.1 255.255.255.255 null 0 tag 666
ipv6 route vrf INET 2001:1::1/128 null 0 tag 666
!
route-map RTBH
 match tag 666
 set community 100:666 no-export
!
router bgp 100
 add ipv4 vrf INET
  redistribute static route-map RTBH
 add ipv6 vrf INET
  redistribute static route-map RTBH

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

#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
```

## Explanation <a href="#id-37c1bef2-6ada-4fb6-9644-990fa5940f34" id="id-37c1bef2-6ada-4fb6-9644-990fa5940f34"></a>

When using RTBH in a VRF, we must apply the route-policies/route-maps to the VPNv4/VPNv6 BGP AFIs.

On IOS-XR, we can simply set the next-hop to discard. We apply this policy to routes received from the RR. On IOS-XR, we are already sending both communities to iBGP neighbors as well, so we don’t need to worry about that. (This router is not the trigger router anyways, so it doesn’t actually matter for this particular lab).

```
#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
```

On IOS-XE, we have some additional steps to take. First, we need to make sure we are sending both communities. By default, for VPNv4/v6, only extended communities are sent.

```
#R2, R4, R5 (PEs)
router bgp 100
 add vpnv4
  neighbor 3.3.3.3 send-community both
 add vpnv6
  neighbor 3.3.3.3 send-community both

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

Next, we define the community and match VPNv4/v6 routes with this community, setting the nexthop to a dummy nexthop, which recurses to a null0 route. Unfortunately, IOS-XE does not have a “set ip next-hop discard” option. Instead, we use an IPv4 test prefix as the dummy null0 route. Notice that this route exists in the global RIB. This is because the global RIB is used to resolve VPNv4/v6 nexthops. (These are usually PE loopback addresses in the global RIB). For VPNv6, we use an IPv4-mapped IPv6 address so that a single IPv4 null0 route can be used for both VPNv4 and VPNv6.

```
#R2, R4, R5 (PEs)
ip community-list standard RTBH permit 100:666
!
ip route 192.0.2.1 255.255.255.255 null0
!
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
 add vpnv4
  neighbor 3.3.3.3 route-map IBGP_VPNV4_IN in
  neighbor 3.3.3.3 send-community both
 add vpnv6
  neighbor 3.3.3.3 route-map IBGP_VPNV6_IN in
  neighbor 3.3.3.3 send-community both
```

Finally, the trigger router, R4, injects the prefixes into the INET VRF setting the community to 100:666 and **no-export**. It is important to set **no-export** so that the prefix is not leaked to INET peers.

```
#R4 (Trigger router)
ip route vrf INET 1.1.1.1 255.255.255.255 null 0 tag 666
ipv6 route vrf INET 2001:1::1/128 null 0 tag 666
!
route-map RTBH
 match tag 666
 set community 100:666 no-export
!
router bgp 100
 add ipv4 vrf INET
  redistribute static route-map RTBH
 add ipv6 vrf INET
  redistribute static route-map RTBH
```

## Verification <a href="#id-5ee7dec6-e081-4add-92d6-24b5a5637bf0" id="id-5ee7dec6-e081-4add-92d6-24b5a5637bf0"></a>

All PEs should be dropping traffic destined for 1.1.1.1/32 or 2001:1::1/128 in the INET vrf. The quickest way to check this is to check the VRF FIB.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FynV21UJacn6LxACIjVAv%2Fimage.png?alt=media&#x26;token=35d86850-32d8-4690-a5df-0a0f44ee414a" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FJdsH1wXqC7zGJR0eYuEJ%2Fimage.png?alt=media&#x26;token=bf43b5ff-de0d-4b99-a894-25986cbf12ce" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FiZI8yHbXwcXtDDwDZyCJ%2Fimage.png?alt=media&#x26;token=0b42f934-db5c-4df5-a583-b3514e19c1db" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FseW3K9pHrW3mEdjdIWYT%2Fimage.png?alt=media&#x26;token=e58ce105-592b-4222-bf4e-1dba4b9fa8f4" alt=""><figcaption></figcaption></figure></div>

A traceroute from any CE to 1.1.1.1 and 2001:1::1 should be dropped at the first PE:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FLrj9f5rO2A89iO5G2H5O%2Fimage.png?alt=media&#x26;token=10bfb926-534a-492d-a680-c534283368d2" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FiTAdNnUWSnbjy6ljR02Y%2Fimage.png?alt=media&#x26;token=bc3efa07-0c01-4af3-a360-82abb9d14650" alt=""><figcaption></figcaption></figure></div>

Also, none of the PEs should see the /32 or /128 route because of the **no-export** community.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FpoNBCYIBRpzbMXPQhJXs%2Fimage.png?alt=media&#x26;token=b3c7628e-fa1d-4fb9-bee7-9ac47de449e1" alt=""><figcaption></figcaption></figure></div>
