Destination-Based RTBH

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.

Configure destination-based RTBH within AS20 and blackhole traffic destined to 50.0.0.8. Use R2 as the trigger node.

Answer

#R2, R4, R5
ip route 192.0.2.0 255.255.255.255 null0

#R2
ip route 50.0.0.8 255.255.255.255 null0 tag 666
!
ip community-list 1 permit 20:666
!
route-map RTBH
 match tag 666
 set community no-export 20:666
!
route-map IBGP_OUT
 match community 1
 set ip next-hop 192.0.2.0
route-map IBGP_OUT permit 20
 set ip next-hop self
!
router bgp 20
 template peer-policy IBGP
  no next-hop-self
  route-map IBGP_OUT out
  send-community
 exit-peer-policy
 !
 redistribute static route-map RTBH

Explanation

In this scenario, AS20 is protecting the destination 50.0.0.8/32 which is undergoing a DoS attack. AS20 will stop sending any traffic to 50.0.0.8/32. In fact, it will discard traffic destined for 50.0.0.8/32 at its edge, also protecting and saving bandwidth internally within AS20.

To do this, we configure a dummy null0 route, which we can use as a nexthop for prefixes we want to blackhole.

#R2, R4, R5
ip route 192.0.2.0 255.255.255.255 null0

Next, on R2, we configure static redistribution into BGP and set the community to no-export. We match static routes with a tag of 666 for prefixes which should be blackholed.

#R2
route-map RTBH
 match tag 666
 set community no-export
!
router bgp 20
 template peer-policy IBGP
  send-community
 exit-peer-policy
 !
 redistribute static route-map RTBH

This works, but R2 is currently setting next-hop-self on its iBGP sessions. This means all internal AS20 routers will divert traffic for the blackholed prefix to R2. This is inefficient - we want all routers to locally drop the traffic. To do this, we add a community of 20:666 on R2, and for routes matching this community we set nexthop to 192.0.2.0 (route-map seq 10). All other routes have the regular next-hop-self (route-map seq 20).

#R2
ip community-list 1 permit 20:666
!
route-map RTBH
 match tag 666
 set community no-export 20:666
!
route-map IBGP_OUT
 match community 1
 set ip next-hop 192.0.2.0
route-map IBGP_OUT permit 20
 set ip next-hop self
!
router bgp 20
 template peer-policy IBGP
  no next-hop-self
  route-map IBGP_OUT out
  send-community
 exit-peer-policy
 !
 redistribute static route-map RTBH

Finally, to trigger the blackhole, all we have to do it inject the static route on R2.

#R2
ip route 50.0.0.8 255.255.255.255 null0 tag 666

Verification

Before triggering the blackhole, notice that R10 and R4 can both reach 50.0.0.8.

We then implement the blackhole trigger on R2, but R2 is setting next-hop-self on its iBGP sessions. R10 can no longer reach 50.0.0.8. R4 is diverting traffic to R2 instead of null routing it locally.

Next we change the R2 configuration to set the next-hop to 192.0.2.0 for routes tagged with 20:666. The result is that R4 null routes the destination instead of routing it towards R2.

Summary

Destination RTBH allows an AS to drop traffic destined to a blackholed IP at the edge. Destination RTBH protects the blackholed IP by not flooding the destination AS with DoS traffic.

It works using:

• A common dummy null0 static route on all routers in the AS (at least all routers on the edge)

• A single router designated as the RTBH trigger (R2 in our lab)

  • This router redistributes static into BGP. You should tag the statics so that only the remote trigger routes are redistributed.

  • Additionally, you might want to use a community and an outbound route-map for iBGP peers so that the nexthop is set to the dummy null0 nexthop, not nexthop self.