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
#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
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.”
#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:
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”:
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.
