irp demo
Request Noction IRP Demo

Request a personalized demo/review session of our Intelligent Routing Platform

irp trial
Start Noction IRP Trial

Evaluate Noction IRP, and see how it meets your network optimization challenges

nfa demo
Noction Flow Analyzer Demo

Schedule a one-on-one demonstration of our network traffic analysis product

nfa trial
Free Noction Flow Analyzer Trial

Test drive NFA today with your own fully featured 30-day free trial

The Number of the Beast or the Practical usage of the Blackhole Community

bgp blackhole BGP blackhole filtering is a routing technique used to drop unwanted traffic. Black holes are placed in the parts of a network where unwanted traffic should be dropped. For example, a customer can ask a provider to install black hole on its provider edge (PE) routers to prevent unwanted traffic from entering a customer’s network.

Unwanted traffic that floods networks and machines from many different sources is often intentionally generated by the distributed-denial-of-service (DDoS) attack. The goal of a DDoS attack is the depletion of resources (CPU, RAM, bandwidth) of a remote target so that the service becomes unavailable for legitimate users. Typical symptoms of a DDoS attack are excessive bandwidth utilization on a targeted network and services crashing on victim’s machines. At the time when the day-long DDoS attacks against a small organization are offered for as low as $100, with a 5-minute test DDoS attack free of charge (showing the attacker capabilities), the importance of having a reactive defense strategy against such attacks is hard to underestimate.

DDoS traffic should be blackholed (dropped) closest to the source of the attack. Blackholing is based on either the source or destination IP address. Remote black hole filtering based on the destination IP address is a commonly used technique. The ISP sets a permanent static route utilizing the unused prefix pointing to the null interface on its PE routers, e.g. It is a precaution measure that ISP installs in advance along with building a trigger machine. The trigger machine is a router or Unix machine running BGP daemon that is a part of ISP infrastructure. It has established internal BGP (iBGP) sessions with PE routers.

Let’s say that a DDoS attack is launched against a customer web server with IP address As soon as a customer asks an ISP to filter the currently running DDoS, the ISP creates a static route to the targeted prefix on the trigger machine pointing to a null interface. The static route to is then redistributed via iBGP sessions from the trigger to PE routers but with the next hop changed to the IP As a result, all traffic to the IP address is sent to the thus is effectively being dropped by the null route on PE routers. When the DDoS attack is finished, the static route is removed from the trigger machine and withdrawn via iBGP session from the PE routers.

The method mentioned above requires customers to send an email to a service provider, requesting manual configuration of the null static route for targeted prefix on a trigger machine when DDoS attack is launched. Subsequently, a customer needs to send an email requesting the removal of a static null route once the DDoS attack is finished. Although this method has been  proven to work, it inserts a time delay into the attack mitigation process. Luckily, there is another, automated method for destination-based remote blackholing using Blackhole Community, which gives customers better control over the black holed prefixes.

The BGP blackhole transitive community is one of the well-known BGP communities defined in RFC 7999. The BGP blackhole community is attached to an announced prefix by an origin Autonomous System (AS) during a DDoS attack. Its purpose consists of signaling to a neighboring network that a neighbor router should discard all traffic destined for the received prefix with the attached BGP blackhole community. With this approach, customers can trigger blackholing of the targeted prefix by remote ISP routers, adding a simple configuration to their customer edge routers. In other words, blackholing can be initiated any time by customers requiring no cooperation with ISP during a DDoS attack. However according to RFC, accepting  the blackhole community, or ignoring it, is a choice that is made by each operator. That is why accepting blackhole community must be agreed by both networks prior to advertising it.

The blackhole community is registered in the “BGP Well-known Communities” registry as 0xFFFF029A. The low-order two octets in decimal are 666. We can only speculate why the value 666 (the number of the beast from the Bible) was chosen for this purpose. Nevertheless, the value is commonly used with BGP blackholing by network operators. As for a length of the blackhole prefix, it should be as long as possible. This prevents discarding traffic sent to the IP addresses that are not under the DDoS attack. Typically the length of a blackhole prefix is /32 (a single IP address). In any case, the length of the announced blackhole prefix must be equal or longer than the length of the entire IP prefix assigned to a customer.  

Below is a network topology that we use for testing of blackhole community usage. In our scenario, an attacker launched a DDoS attack against the customer web server (IP If our configuration is correct as soon as the customer configures the commands below, DDoS traffic should be discarded on a router ISP. Traffic from the attacker to IP address should not be discarded.

ip route Null0
router bgp 64501
network mask route-map blackhole

blackhole communities

Picture 1 – Network Topology

1. Customer Router Configuration

ip bgp-community new-format

router bgp 64501
bgp log-neighbor-changes
network mask route-map blackhole
neighbor remote-as 64500
neighbor send-community

ip route Null0

route-map blackhole permit 10
set community 64500:666

2. ISP Router Configuration

interface Null0
no ip unreachables

The command above stops sending ICMP unreachables to the attacker when DDoS packets are discarded on an ISP router.

router bgp 64500
bgp log-neighbor-changes
network mask
network mask
neighbor remote-as 64501
neighbor ebgp-multihop 255
neighbor route-map customer-in in
neighbor remote-as 64502ip bgp-community new-format
ip community-list 10 permit 64500:666ip route Null0route-map customer-in permit 10
match community 10
set community no-export
set ip next-hop customer-in permit 20


NOTE: Altering the next-hop for blackhole services requires multihop on the EBGP sessions otherwise the route won’t be selected as a best route and inserted into the routing table of an ISP router.

3. Additional Configuration on ISP PE Router

3.1. Restrict Customer to Advertise Only Authorized Prefix with Length from /24 to /32

Customer should only announce a prefix that is authorized to advertise (, with the length from /24 to /32. For this reason ISP needs to filter BGP announcements carrying the blackhole community that are not authorized.

ip prefix-list AS64501-in seq 5 permit le 32

router bgp 64500
neighbor prefix-list AS64501-in in

3.2. Prevent ISP to send Blackhole Prefix to eBGP Peers

A BGP speaker receiving an announcement tagged with the blackhole community (ISP) should add no_export community as to prevent propagation of the blackhole prefixes to eBGP peers. We have already done it with the command under the route-map customer-in in the ISP configuration.

4. Testing

If the DDoS attack is not launched, the attacker can ping the IP address

Attacker# ping repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (50/50), round-trip min/avg/max = 1/1/2 ms

Below is the RIB of the ISP router.

ISP# show ip bgp | begin Network 
    Network          Next Hop            Metric LocPrf Weight Path 
*>             0             0 64501 i 
*>                  0         32768 i 
*>                  0         32768 i

Once the DDoS attack is launched and detected by the customer, the customer adds the following lines to its router. Subsequently, once the attack is finished, the customer removes the lines from the configuration.

ip route Null0

router bgp 64501
network mask route-map blackhole

The RIB of an ISP router changes adequately. We see that route with the next hope was added.

ISP#show ip bgp | begin Network 
    Network          Next Hop            Metric LocPrf Weight Path 
*>             0             0 64501 i 
*>                0             0 64501 i 
*>                  0         32768 i 
*>                  0         32768 i

Inspection of the static route to reveals that packets to the IP address are discarded.

ISP# show ip route static | begin is subnetted, 1 subnets 
S is directly connected, Null0

The RIB of the attacker router has not changed.

Attacker# show ip bgp | begin Network 
    Network          Next Hop            Metric LocPrf Weight Path 
*>                           0 64500 64501 i 
*>             0             0 64500 i 
r>             0             0 64500 i

However DDoS traffic is successfully discarded on the ISP router.

Attacker# ping repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 0 percent (0/5)

The traffic to the IP address should not be discarded as the DDoS attack is launched only against the web server.

Attacker# ping repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (50/50), round-trip min/avg/max = 1/1/2 ms


5. Intelligent Routing Platform – Automated Threat Mitigation

Starting with v 4.1, IRP offers a fully automated threshold-based DDoS detection and mitigation instrument that uses FlowSpec and the Remote Triggered Blackholing mechanisms to defend your network against small and large-scale attacks.

IRP’s Threat Mitigation can operate in either automated or moderate modes. However, it is also extremely easy for the platform users to monitor and set up custom blackholing rules when such are required.

With this feature set up, there is no need for you to ssh to the remote trigger routers and type in specific configurations in the middle of the night. DDoS detection/mitigation becomes much easier, less time-consuming, and stress-free.

automated thread mitication

We should note that there are some pros and cons associated with the use of the BLACKHOLE community. While this approach is widely supported by transit providers, accepting the blackhole community, or ignoring it, as mentioned above, is a choice that is made by each operator. The use of the community should be agreed by both networks.

Moreover, one should be cautious about the possible abuse and the dangers of the BGP community attributes and the remote triggered blackhole mechanism (RTBH) described in The dark side of BGP community attributes article.

Boost BGP Preformance

Automate BGP Routing optimization with Noction IRP

bgp demo


You May Also Like