Source-Based RTBH (VRF Provider-triggered)

Topology: ine-spv4

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