The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

Source-based RTBH

By stretch | Monday, August 23, 2010 at 2:41 a.m. UTC

A while back, I wrote about Remotely-Triggered Black Hole (RTBH) Routing. The basic implementation we examined there is destination-based: traffic can only be discarded based on destination IP addresses. As several commenters pointed out, this is approach is limiting. While it allows for efficient traffic filtering, it is often more desirable to block only traffic originating from certain source address ranges rather than all traffic intended for a single destination. In this article we'll see how we can extend the RTBH concept to filter against source addresses as well.

The key component of source-based RTBH (S/RTBH) is the addition of Unicast Reverse Path Forwarding (uRPF). (For an example of how uRPF might be employed in its own right, check out Using uRPF at the access layer to deter DDoS attacks.) uRPF is discussed in RFC 3704 (BCP 84), and is essentially this: The source address of an incoming packet is looked up in the FIB. If there is a FIB entry for the address pointing out the interface on which the packet was received, the packet is allowed to pass. If not, the packet is discarded. (uRPF loose mode requires only that an entry matching the source IP address exists; it does not care whether the outgoing interface matches.)


We can combine uRPF with RTBH to filter against source IP addresses.

To recap the prior article on RTBH, first we set up our null route on all BGP routers, including our route server. It is assumed that a functional iBGP network is already in place.

R1(config)# ip route Null0
R2(config)# ip route Null0

Next, we create a route map to manage the redistribution of static routes into iBGP on our route server. The examples here and in the prior article matches routes based on a specific tag value, 666.

BHServer(config)# route-map S/RTBH
BHServer(config-route-map)# match tag 666
BHServer(config-route-map)# set ip next-hop
BHServer(config-route-map)# set origin igp
BHServer(config-route-map)# set community no-export

Finally we apply this route-map to the BGP process on the route server.

BHServer(config)# router bgp 65000
BHServer(config-router)# redistribute static route-map S/RTBH

At this point, we're ready to support destination-based RTBH. Let's take our configuration one step further and enable loose mode uRPF on autonomous system edge interfaces.

R1(config-if)# ip verify unicast source reachable-via any
R2(config-if)# ip verify unicast source reachable-via any

Be aware that enabling uRPF on a real network, even in loose mode, has implications that are beyond the scope of this article. Although it can bring substantial benefits, enabling it across your network is an important design decision that must be given its due consideration.

Cisco has produced an excellent white paper on RTBH (PDF), which explains how uRPF is used to accomplish source-based RTBH:

Loose URPF checks the packet and forwards it if there is a route entry for the source IP of the incoming packet in the router FIB. If the router does not have a FIB entry for the source IP address, or if the entry points to Null0, the Reverse Path Forwarding (RPF) check fails, and the packet is dropped.

By using the RTBH method to inject routes pointing to Null0 on edge routers, we can cause a uRPF failure for any given source IP address.

Suppose an edge router begins receiving a massive amount of traffic spoofed from the IP address We can inject a route for this IP address with a next-hop of (our black hole route to Null0) to drop any traffic sourced from this address. Remember to include the tag on the static route.

BHServer(config)# ip route tag 666
R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set is subnetted, 1 subnets
B [200/0] via, 00:00:21 is subnetted, 1 subnets
C is directly connected, FastEthernet0/1 is subnetted, 2 subnets
C is directly connected, FastEthernet0/0
O [110/20] via, 00:57:49, FastEthernet0/0 is subnetted, 1 subnets
S is directly connected, Null0

Note that while we've achieved source-based black holing with uRPF, destination-based black holing is also in effect because of the null route. Any packet entering an edge interface will be dropped if it has a black-holed IP as either its source or destination address.

Posted in Routing, Security


August 23, 2010 at 2:55 a.m. UTC

Good article stretch!

Roland Dobbins
August 23, 2010 at 9:29 a.m. UTC

Also see the section on S/RTBH in this presentation:

August 23, 2010 at 12:43 p.m. UTC

Never come in contact with this yet, but glad to have a few posts to refer to as a start-up. Thanks Stretch!

Daniel Kratz
September 19, 2010 at 2:35 p.m. UTC

Thanks for the good document. I have two comments:

  • To deep into troubleshooting, CEF is a nice place to start. Source-based RTBH advertised prefixes are not installed on CEF table.

  • Another troubleshooting tricks is look ip RPF drops on output of “show ip interface”. In a live network some time is hard to call the is all working fine.

April 9, 2015 at 4:59 p.m. UTC

Hi guys,

I've a doubt about RTBH. What's the main diference of the discard on interface via uRPF, and discard via Null0 ?

Exist any performace gain, at discard via uRPF in the Interface ?

Thks of all

Comments have closed for this article due to its age.