Source-Based RTBH (Community-Based)

Topology: bgp-mh-iol

configure replace unix:init.cfg

• All links are in the format 100.X.Y.X/24.

  • For example, the link between R4 and R7 is 100.4.7.0/24.

• Lo0 is X.X.X.X/32 and is used for iBGP

• Lo1 is <AS>.0.0.X/32 and is used as a public IP address that is pingable. The public Lo1 addresses are aggregated into a /8 at each edge router.

• eBGP and iBGP is fully preconfigured.

Instructions:

• Configure source-based RTBH for 10.0.0.1/32 within AS20.

  • R2 should drop traffic sourced from this IP at the edge.

• Use the least restrictive method when dropping traffic inbound.

• Use R4 as the blackhole trigger point, using communities to signal the blackhole from R4 instead of nexthop.

Answer

#R2, R5
ip route 192.0.2.1 255.255.255.255 null 0
!
ip community-list standard RTBH permit 20:666
!
route-map IBGP_IN
 match community RTBH
 set ip next-hop 192.0.2.1
route-map IBGP_IN permit 20
!
router bgp 20
 template peer-policy IBGP
  route-map IBGP_IN in

#R4
ip route 10.0.0.1 255.255.255.255 null 0 tag 666
!
route-map RTBH
 match tag 666
 set community 20:666 no-export
!
router bgp 20
 template peer-policy IBGP
  send-community standard
 exit
 !
 add ipv4
  redistribute static route-map RTBH
  
#R2
int eth0/1
 ip verify unicast source reachable-via any

Explanation

Using communities is usually a more elegant method to implement RTBH. On IOS-XE, there is no “set next-hop discard” option like there is on IOS-XR. So on the PEs, we must match the RTBH community and set the next-hop to a dummy null0 route.

#R2, R5
ip route 192.0.2.1 255.255.255.255 null 0
!
ip community-list standard RTBH permit 20:666
!
route-map IBGP_IN
 match community RTBH
 set ip next-hop 192.0.2.1
route-map IBGP_IN permit 20
!
router bgp 20
 template peer-policy IBGP
  route-map IBGP_IN in

On R4, we trigger the RTBH. We must match the static route like usual, and set the community to 20:666 and no-export. This is a bit more elegant than the previous solution, because we do not have to a complicated route-map that changes the nexthop to our iBGP peers based on the community. (next-hop=192.0.2.1 for RTBH routes, and next-hop=self otherwise). Instead, the community itself is what triggers blackholing on the remote PEs. Make sure to send community to the iBGP peers as well.

#R4
ip route 10.0.0.1 255.255.255.255 null 0 tag 666
!
route-map RTBH
 match tag 666
 set community 20:666 no-export
!
router bgp 20
 template peer-policy IBGP
  send-community standard
 exit
 !
 add ipv4
  redistribute static route-map RTBH

Finally, on R2, we implement loose uRPF on the interface facing R1 again.

#R2
int eth0/1
 ip verify unicast source reachable-via any

Verification

Verification is similar to the previous lab. First, we can verify on R2 that the 10.0.0.1/32 prefix was received from R4 with the correct community, and that the nexthop was changed to our dummy null0 route.

If we source pings from R1, we should see the uRPF drops increment on eth0/1.