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
#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
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
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.
A traceroute from any CE to 1.1.1.1 and 2001:1::1 should be dropped at the first PE:
Also, none of the PEs should see the /32 or /128 route because of the no-export community.
