GNS3 Labs: BGP Customer triggered black holing

This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned! 😉

Remote Triggered Black Holing In this post I’ll show you how to let your customers to trigger black holing for their prefixes. What I will write is based on my previous post GNS3 Lab: Remote Triggered Black Holing: same scenario, same startup config (the final one of that post).

What is customer triggered blackholing?

Suppose a customer notices one of its hosts is under attack; using customer triggered black holing he can stop malicious traffic toward the attacked host at the ISP edge, and he can do this without the need to ask the provider’s NOC to run RTBH.

While the customer’s staff is analyzing the attack, other hosts remain reachable from the outside, because just the attacked host has been black-holed. Furthermore, all RTBH features can be used: if the customer knows the attack is coming into ISP network from a specific upstream provider, he can just black-hole the attacked prefix on the ISP edge routers facing this specific provider, maintaining full service for networks behind other upstream providers. Of course, when the attack is over, he can resume the prefix and the regular traffic toward it, always avoiding to ask provider’s NOC.

Customer-triggered blackholing let our customers to lower their response time against attacks and it also lower work load and liability of our NOC.

How does it work?

To let our customers to activate RTBH we just need them to announce prefixes they want to black-hole using the specific BGP community. For example, if customer 10 (AS 65310) wants to black-hole toward ISP2 (AS 200) he just has to announce that prefix with community 300:102.

As we already did in the Core router, our customers will trigger RTBH just adding a tagged static route toward the prefix they want to blackhole.


On the customers routers we need to add the send-community keyword to the neighbor, in order to let them to send communities to our Edge router:

Cust10(config)#router bgp 65310
Cust10(config-router)#neighbor send-community
Cust20(config)#router bgp 65320
Cust20(config-router)#neighbor send-community

We need to set send-community in our Edge router too, so that it could send communities to our RR:

Edge3(config)#router bgp 300
Edge3(config-router)#neighbor send-community

Our RR router already has the send-community keyword, so it already sends communities to other peers (RR clients):

Core#sh run | sec bgp
router bgp 300
 no synchronization
 bgp log-neighbor-changes
 redistribute static route-map RTBH
 neighbor Edge peer-group
 neighbor Edge remote-as 300
 neighbor Edge update-source Loopback0
 neighbor Edge route-reflector-client
 neighbor Edge send-community
 neighbor Edge soft-reconfiguration inbound
 neighbor peer-group Edge
 neighbor peer-group Edge
 neighbor peer-group Edge
 no auto-summary

(look at the neighbor Edge send-community line)

Now, we need to add the RTBH route-map to our customers routers; we will match static route tags in order to add the AS300 RTBH community to prefixes:

route-map RTBH permit 10
 match tag 100
 set community 19660900
route-map RTBH permit 20
 match tag 101
 set community 19660901
route-map RTBH permit 30
 match tag 102
 set community 19660902
route-map RTBH permit 40
 match tag 199
 set community 19660999
route-map RTBH deny 1000

As opposed to the Core router’s RTBH route-map, here we have to remove the no-export community from the set community statements, otherwise black-holed prefixes will not cross the customer’s AS borders.

Now we just have to redistribute static routes into BGP using the route-map:

Cust10(config)#router bgp 65310
Cust10(config-router)#redistribute static route-map RTBH
Cust20(config)#router bgp 65320
Cust20(config-router)#redistribute static route-map RTBH


At this point, customers just have to add static routes for their attacked prefixes to black-hole traffic at AS300 edges:

Cust10(config)#ip route fa1/0 tag 100

In the example, Cust10 announces prefix to our Edge3 router with community 300:100 (19660900):

Edge3#sh ip bgp
BGP routing table entry for, version 19
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1          2
  65310 from (
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 19660900

Edge3 sends it to our RR wich, in turn, reflects it to Edge1 and Edge2 routers:

Edge1#sh ip bgp
BGP table version is 3, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i192.168.10.0              0    100      0 65310 i
*>i192.168.10.20/32                0    100      0 65310 ?

Edge1#sh ip bgp
BGP routing table entry for, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to any peer)
Flag: 0x820
  Not advertised to any peer
  65310 from (
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: no-export no-advertise
      Originator:, Cluster list:

Edge1#sh ip cef, version 22, epoch 0
0 packets, 0 bytes
  via, 0 dependencies, recursive
    next hop, Null0 via
    valid null adjacency
Edge2#sh ip cef, version 22, epoch 0
0 packets, 0 bytes
  via, 0 dependencies, recursive
    next hop, Null0 via
    valid null adjacency

Of course we need strong policy enforcement on the customers facing edge router (Edge3) in order to avoid customers to announce prefixes assigned to other customers, or to use unproper communities.

In this post what I missed to implement is customer triggered blackholing on the same Edge3 router. Indeed there is not a route-map which sets next-hop to null0 for blackholed prefixes. This solution works fine for global and ISP-specific blackholing, but not for customers blackholing. To achieve this goal more work is needed, maybe I will write another post about this! 😉

Download the lab

You can download the GNS3 Lab here. Within the .zip file, in the config directory, you can find the previous post configurations and the new “4. Customer trigger blackholing” subdirectory containing the final config.

The following two tabs change content below.
Italian, born in 1980, I started working in the IT/telecommunications industry in the late '90s; I'm now a system and network engineer with a deep knowledge of the global Internet and its core architectures, and a strong focus on network automation.

Latest posts by Pier Carlo Chiodi (see all)


  1. […] UPDATE 2009-06-21: You can find a related solution to use customer triggered blackholing in this new post! […]

  2. […] Terry’s Blog « GNS3 Labs: BGP Customer triggered black holing […]

  3. LnddMiles says:

    Great post! I’ll subscribe right now wth my feedreader software!

  4. Unixxx says:

    Hi, i am trying to load the gns configuration files but i get an error saying

    Warning: Could not connect to dynamips server
    Errors: error during loading of the topology file, please correct them

    please how do i solve this. thanks

    • pierky says:

      Hi Unixx, you can try to edit the .net file (you can use a simple text editor like Notepad) and replace with localhost. I hope this works!

  5. optix says:

    How is the customer authenticated? I mean what stops any IP in the AS from blackholing any other IP?

  6. Praveen says:

    could u pls tell about book name where i get this topic Sam halabi book has not this

  7. […] 2. BGP Customer triggered black holing […]

Leave a Reply