I have a question regarding BGP and how to achieve this configuration.

My enterprise core router is connected to an ISP (single homed). This router has already exchanged the specific public ip prefixes to the ISP in BGP updates. Now lets says there is an AS several hops away that is flooding my local AS with a DDoS attack. There are multiple networks in that AS targeting the web servers in my local AS.

How can we stop this traffic on our router by using BGP?

Appreciate your response!! :)

  • 2
    How did you establish the source of this traffic? If you were only looking at the source IP addresses, those might be spoofed. A flood of packets all spoofing source addresses within a single AS is what you would see, if a reflection attack is happening.
    – kasperd
    Commented Sep 9, 2014 at 9:49
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Commented Jan 3, 2021 at 2:10

6 Answers 6


There are two things you could do with BGP:

RTBH - Remotely-Triggered Black Hole

First option is the radical one: Blackhole (stop traffic) for the IP getting attacked. Downside: The IP being targeted is no longer reachable. Benefit: The rest of your network stays up. Packetlife has a nice explanation on how it work and how to do it. The second option builds on the first one:

Source-Based RTBH

RTBH can also be used (in certain configurations) to block traffic coming from specific IPs (in a real DDoS that wouldn't help much as traffic would come in from thousands of IPs). Again, Packetlife has an explanation.

In your case you could get all prefixes for the AS from a Routing Database like RADB and block these with Source-Based RTBH. Traffic would still hit your network at the border though.

When you use "simple" RTBH the advantage is that you can send these RTBH routes to your Upstream ISP (if they support it) who could then block the traffic in their network already so you don't have to handle it.

  • The method described by Packetlife is helpful, but it won't be of any use in a scenario where your uplinks are saturated by attack traffic. I wrote up an answer on using upstream blackhole communities to address this issue.
    – Elliot B.
    Commented Sep 11, 2014 at 0:32
  • 2
    It's in my last sentence: "When you use "simple" RTBH the advantage is that you can send these RTBH routes to your Upstream ISP (if they support it) who could then block the traffic in their network already so you don't have to handle it." Commented Sep 11, 2014 at 11:23
  • I saw that, but I wanted to detail the customer-triggered blackhole method and point out that "[not having] to handle it" means that the blackhole would not be effective otherwise. Not intended to be a knock on your answer, just providing more information :)
    – Elliot B.
    Commented Sep 11, 2014 at 18:49

The RTBH method described by @Sebastian via Packetlife is helpful, but that method will only work if your uplink is not saturated by attack traffic. If your uplink is saturated, then the blackhole must be implemented at a point before the attack traffic reaches your network.

You can accomplish this with upstream blackhole communities.

Hurricane Electric offers a simple explanation/example of customer-triggered blackholing with a BGP community:

  1. Attack Starts
  2. Customer identifies ip or ip range under attack
  3. Customer static routes the ip or ip range to Null0 and adds an announcement of the corresponding prefix with a route map that tags it with 6939:666.

Cisco configuration example (where X.X.X.X is the ip being attacked):

conf t
ip route X.X.X.X Null0
router bgp YourAS
network X.X.X.X mask route-map blackhole
route-map blackhole permit 10
set community 6939:666

Note that 6939:666 is the blackhole community specific to Hurricane Electric. You would modify this value to correspond with the blackhole community of your upstream provider.

There are of course multiple ways to configure this. On my Brocade gear, I use the following configuration:

router bgp
redistribute static route-map blackhole
route-map blackhole permit  5
 match tag  66
 set community  55555:666

Where 55555:666 is the blackhole community of your upstream provider. An upstream blackhole can then applied with a simple command:

ip route null0 tag 66

From a BGP perspective, there is not much you can do. You could stop advertising your prefix but then you are just completing the DoS attack because noone will be able to access your service.

If you have multiple prefixes you could renumber but likely the attack will move to the new prefix as well.

What you need to do is to work with your upstream. Do they have a scrubbing service? If they have a system such as Arbor Peakflow, they could scrub the traffic and clean it before it enters your network. Such services are often very expensive.

There are also other options such as Cloudflare and similar companies where you setup BGP through a GRE tunnel to that company and your traffic gets handled by their "cloud" which can handle a lot more traffic than your local devices.


I work for CloudFlare, I'd like to share some of the knowledge I've developed about mitigating DDOS attacks over the last few months I've been here.

Firstly; a lot of people resort to network level measures to mitigate application layer DDOS attacks. Before diving to BGP Blackholing, consider whether it's something rate limiting or application layer protection could deal with. That said; it's now very cheap to launch very large capacity DDOS attacks (given how many Open DNS Recursors are around, and how they can amplify attacks).

As Elliot described in his answer, using BGP Communities to blackhole traffic can work well if your network is small; this mechanism is documented in RFC 3882. However, like us, if you instead you wish to absorb the attack traffic instead of blackhole (i.e. you want to collect DDOS attack data), then beware of collateral damage whereby intermediary network providers end up being congested. You can mitigate the collateral damage by peering directly with the ISPs of the networks who are launching the attacks. By doing so you have the shortest path from attacker to destination. Additionally you can implement an Anycast network design, this will effectively mean one IP address hits multiple datacenters (depending on whichever is closest).

Obviously it's not possible for every company to have the infrastructure to do Anycast and peering; that's why businesses are increasingly turning to cloud services to remove the bad traffic before it reaches their datacenters. Naturally CloudFlare is one such service.


If all the evidence you have collected is a flood of packets with source IP addresses from one particular AS, you have likely jumped to the wrong conclusion. A more likely explanation would be that those source IPs are spoofed.

A reflection/amplification attack involves sending lots of packets spoofing the source IP address of a victim. If this is actually what is happening, and you have servers in your network, that can amplify an attack, then the network you are accusing of an attack is actually the victim, and you are aiding the attacker.

In such a situation the solution is not to apply any sort of traffic engineering, but rather to configure your servers such that they cannot be used in an amplification attack. How to do this is not really a network engineering question.

It is of course possible, that all the packets are originating from one AS. With co-operation from the offending AS, you could get confirmation, that the packets do in fact originate from their AS. However with that level of co-operation, you could also get the attack blocked at the source.

If we assume you have through some method I haven't thought about gotten confirmation the packets are really originating from the AS you think, and that you cannot get it blocked at the source and instead want to block it through means of BGP, then I have read about a somewhat risky method to achieve this. The idea is that you prepend an AS path to the route you are announcing. In this prepended AS path you include the AS number of the source of those packets.

When the announcement reaches the BGP routers in the offending AS, they are going to detect a loop and drop the announcement. Meanwhile the rest of the world won't see a loop and accept the announcement.

That's the theory. Whether it will actually work in practice depends on a few different factors. For example it depends on actually using the AS number the packets are originating from, which could be different from the AS number announcing those IP addresses. (Such difference could be legitimate or due to spoofing.)

It also depends on your upstream not filtering the route if they find the AS path suspicious. Moreover networks further away from you may also drop your route for example if they also has had bad experiences with the offending AS and have decided to drop all routes from there.

It's your call whether this approach is worth the risk.

(I would have linked to the source for this approach, if I could find it again.)

  • 2
    That is a very dangerous thing to do. You are spoofing another AS in your path that you not own. Also if other people drop routes from that AS they will drop your routes as well. Commented Sep 9, 2014 at 8:44
  • 1
    @Sebastian True, that risk also exists. But if the alternative is a network which is unreachable due to being flooded with traffic, it may be worth the risk.
    – kasperd
    Commented Sep 9, 2014 at 9:21
  • This sounds like a very bad idea, I've never heard of it before. It breaks connectivity for an entire ASN when there's one botnet node, which isn't what you want for e.g. large cloudproviders. Also, it scales badly with DDoS'es where thousands of botnet nodes are attacking something in your network.
    – Teun Vink
    Commented Sep 9, 2014 at 9:33
  • 1
    @TeunVink It is definitely not applicable to a typical DDoS attack. But the OP isn't asking about a typical DDoS attack. He is asking about an attack where all of the traffic is originating from one AS. Breaking connectivity to one AS would be acceptable, if the alternative was an attack breaking connectivity to the entire internet.
    – kasperd
    Commented Sep 9, 2014 at 9:43

You can blackhole their AS from your local network, so your BGP router creates null routes for any prefix they announce.


  • your AS will appear dead to them, which is their goal, while you still exchange data with everyone else normally.
  • your local ingress filtering will automatically drop incoming packets from that AS


  • they can create blackhole routes on your router, so be sure to have appropriate rules in place to keep your most vital routes intact
  • 1
    Blackholing an entire AS means you end up DOSing yourself. No one else in that AS can reach you. Your customers might also be in that AS.
    – Ron Trunk
    Commented Sep 8, 2014 at 16:13
  • 1
    I'm assuming a hostile AS here, i.e. noting of value is lost if you block them entirely. There are a few "bulletproof hosting" services I'd file into this category. Commented Sep 8, 2014 at 16:25
  • 1
    Most ASNs aren't completely hostile or friendly, the just contain some hosts which are parts of a botnet. Also, this approach doesn't prevent your upstream links from being flooded, so it will not help you stopping volume based DDoS-attacks.
    – Teun Vink
    Commented Sep 9, 2014 at 9:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.