Jul 10, 2009

Remotely-Triggered Black Hole (RTBH) Routing

Remotely-Triggered Black Hole (RTBH) routing is an interesting application of BGP as a security tool within service provider networks. One common use is mitigation of distributed denial of service (DDoS) attacks, as this article will explore.

Pictured below is a (very) simplified service provider architecture.


Routers 1 through 4 compose the network core, and router 9 functions as a standalone "management" router for route injection. OSPF is running across the core to exchange internal routes. Each router in this core square also maintains an iBGP adjacency with the other core routers, and with router 9. The server at represents the target of a DDoS attack.

Assume a DDoS attack is launched from the public Internet toward the customer server at The throughput consumed is so excessive that the attack is impacting the entire internal infrastructure and must be blocked at the edge. Due to the distributed nature of the attack, we must block at the edge all inbound traffic destined for the victim. Rather than resorting to laborious and error-prone access lists, we can utilize BGP and RTBH to quickly achieve the desired result.

Step 1: Null route preparation

The first two steps in configuring RTBH should ideally be completed prior to an attack.

RTBH works by injecting a specially-crafted BGP route into the network, forcing routers to drop all traffic with a specific next-hop -- effectively creating a "black hole." We create a static route on all BGP routers for this next-hop address:

R1(config)# ip route Null0 

This route forces any traffic destined for to be immediately dropped by the router. This route is added to all edge routers (R1 and R2) in our example lab.

Note that any IP address can be used for this black hole route; we use an IP from the reserved Test-Net range (see RFC 3330) here out of convenience, as this IP should never appear on a routed network.

Step 2: Route-map preparation

As with the first step, this configuration should also be completed prior to an attack.

A route-map is created to redistribute certain tagged static routes into BGP with a modified next-hop value:

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

This is the key component to RTBH: any route advertised to an edge router with a next-hop of will force recursion to the static Null0 route we implemented in the prior configuration, and any matching traffic will be dropped.

Enable static route redistribution into BGP for the route-map to take effect:

R9(config)# router bgp 65100 R9(config-router)# redistribute static route-map RTBH 

Step 3: Create a victim route on the management router

Once an attack is detected and the decision is made to block traffic, a static route for the victim address is created on the management router (R9):

R9(config)# ip route Null0 tag 666 

Ideally, we would like to simply advertise this route to the edge BGP routers, but a route cannot be advertised as having an invalid next-hop. So, we've added a tag value to ensure that our RTBH route-map redistributes the route into BGP with a modified next-hop. Note that the no-export community has been appended here to avoid accidentally exporting the route beyond the local AS.

With our victim route injected, we can verify that the edge routers now drop all traffic bound for that prefix:

R1# show ip route Routing entry for   Known via "bgp 65100", distance 200, metric 0, type internal   Last update from 00:06:14 ago   Routing Descriptor Blocks:   *, from, 00:06:14 ago       Route metric is 0, traffic share count is 1       AS Hops 0  R1# show ip route Routing entry for   Known via "static", distance 1, metric 0 (connected)   Routing Descriptor Blocks:   * directly connected, via Null0       Route metric is 0, traffic share count is 1 

Of course, the victim is now unreachable, and we've effectively assisted the DDoS in accomplishing its goal. However we have protected our internal infrastructure (and other customers) from the flood of traffic, affording us time to better investigate and more eloquently mitigate the attack. As you might imagine, there are more advanced implementations of this method which can be used, as future articles will cover.

Thanks to Steinthor Bjarnason and his BRKSEC-2204 presentation at Cisco Live for inspiring this article!

Late Collision

在ICND1的Troubleshooting章節中,針對一些特定網路狀況的內容其實寫得不是很周全詳密,所以各位有可能會在其他書籍或文件中看到ICND1沒有提到的狀況,比方說 Late Collision 在ICND1指出這個狀況是因為Cable長度過長所導致,其實這只是原因之一而已。


Late Collision is a type of collision found in the CSMA/CD protocol standard. If a collision error occurs after the first 512 bit times of data are transmitted by the transmitting station, a late collision is said to have occurred. Importantly, late collisions are not re-sent by the NIC unlike collisions occurring before the first 64 octets; it is left for the upper layers of the protocol stack to determine that there was loss of data.

As a correctly set up CSMA/CD network link should not have late collisions, the usual possible causes are full-duplex/half-duplex mismatch, exceeded Ethernet cable length limits, or defective hardware such as incorrect cabling, non-compliant number of hubs in the network, or a bad NIC.