R1, XR2, R7 and R8 are all dual-stacked internet peers in an INET VRF. Configure source-based RTBH within the core so that traffic sourced from 1.1.1.1/32 and 2001:1::1/128 is dropped, as well as traffic sourced from 20.20.20.20/32 and 2001:20::20/128. Use R4 as the signaling server, using communities for triggering the RTBH.
Answer
#R2, R5 (PEs)
ip route 192.0.2.1 255.255.255.255 null 0
ip community-list standard RTBH permit 100:666
!
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
exit-address-family
!
address-family vpnv6
neighbor 3.3.3.3 route-map IBGP_VPNV6_IN in
#R4 (Trigger router)
ip route vrf INET 1.1.1.1 255.255.255.255 null 0 tag 666
ip route vrf INET 20.20.20.20 255.255.255.255 null 0 tag 666
ipv6 route vrf INET 2001:1::1/128 null 0 tag 666
ipv6 route vrf INET 2001:20::20/128 null 0 tag 666
!
route-map RTBH
match tag 666
set community 100:666 no-export
!
router bgp 100
address-family vpnv4
neighbor 3.3.3.3 send-community both
exit-address-family
!
address-family vpnv6
neighbor 3.3.3.3 send-community both
!
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
!
int GigabitEthernet0/0/0/0.1920
ipv4 verify unicast source reachable-via any
ipv6 verify unicast source reachable-via any
#R2 (PE)
int gi2.12
ip verify unicast source reachable-via any
ipv6 verify unicast source reachable-via any
Explanation
Source-based RTBH in a VRF is not very different from destination-based RTBH in a VRF. The cleanest way to implement it is to use a community. The IOS-XR PEs can simply match the community and “set next-hop discard.”
#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
However the IOS-XE PEs must use a dummy null0 route in the global VRF. We can take advantage of IPv4-mapped IPv6 nexthops and use a single dummy route.
#R2, R5 (PEs)
ip route 192.0.2.1 255.255.255.255 null 0
ip community-list standard RTBH permit 100:666
!
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
exit-address-family
!
address-family vpnv6
neighbor 3.3.3.3 route-map IBGP_VPNV6_IN in
The triggering router simply tags these routes with the RTBH community and no-export. Make sure to send-community both as well.
#R4 (Trigger router)
ip route vrf INET 1.1.1.1 255.255.255.255 null 0 tag 666
ip route vrf INET 20.20.20.20 255.255.255.255 null 0 tag 666
ipv6 route vrf INET 2001:1::1/128 null 0 tag 666
ipv6 route vrf INET 2001:20::20/128 null 0 tag 666
!
route-map RTBH
match tag 666
set community 100:666 no-export
!
router bgp 100
address-family vpnv4
neighbor 3.3.3.3 send-community both
exit-address-family
!
address-family vpnv6
neighbor 3.3.3.3 send-community both
!
add ipv4 vrf INET
redistribute static route-map RTBH
!
add ipv6 vrf INET
redistribute static route-map RTBH
The RR must send the standard community too.
#R3 (RR)
router bgp 100
template peer-policy IBGP
send-community both
Up until this point we have essentially implemented destination-based RTBH. To do source-based RTBH we just add the loose uRPF check at the ingress PEs.
#XR1 (PE)
int GigabitEthernet0/0/0/0.1920
ipv4 verify unicast source reachable-via any
ipv6 verify unicast source reachable-via any
#R2 (PE)
int gi1.12
ip verify unicast source reachable-via any
ipv6 verify unicast source reachable-via any
Verification
On the ingress PEs, verify that all four routes point to a null0 adjacency in the FIB for the INET VRF.
When the customer routes originate traffic, we should see the uRPF drops increment on R2 and XR1.
The drops for IPv6 on R2 might be a little confusing in the output. It says “0 verification drops” but “5 (CEF)” drops. It seems that when the null0 route is matched, it’s a “CEF drop” instead of a “verification drop.” To be completely sure, we can use an ACL to verify the drops.
#R2
ipv6 access-l LOG-RPF
deny ipv6 any any log
!
int gi1.12
ipv6 verify unicast source reachable-via any LOG-RPF
!
logging con 7
When we ping from R1, we should now see the logging entry:
#R1
ping 2001:7::7 so lo0
Note that if we ping from the other loopbacks on R1 or XR2, traffic works as expected.
