What Happens When a DDoS Attack Exceeds the Uplink Capacity?

When a DDoS attack exceeds the uplink capacity, no filtering run locally at the operator can help: the link is already physically saturated before the traffic reaches the filtering device. In such a situation, the only effective mechanism is RTBH (Remotely Triggered Black Hole) announced toward the transit provider, which drops the traffic before it enters the customer's link.

This is one of the first questions raised in conversations with ISPs and data centers about deploying DDoS protection, and rightly so: it is not a theoretical scenario but everyday reality in networks serving subscriber traffic and hosting.

Anti-DDoS systems based on BGP FlowSpec, including LiveShield, analyze traffic and generate precise filtering rules installed on the operator's edge routers. This mechanism works very well as long as the problem is the nature of the traffic, and not its volume relative to the available bandwidth.

The critical point is this: FlowSpec is announced locally, on routers that are already behind the uplink. If the attack generates more traffic than the link physically carries, part of that traffic will never reach the router with the FlowSpec rule installed: the link will be saturated earlier, no matter how precise the filtering rule is.

In other words: FlowSpec solves the problem of traffic quality on the link, not the problem of traffic volume above the link's capacity.

In a scenario where the attack volume exceeds the uplink capacity, the only mechanism that actually relieves the link is RTBH (Remotely Triggered Black Hole) announced not on your own routers but toward the transit provider (upstream).

RTBH works on a completely different principle from FlowSpec: instead of precisely filtering specific packets, it tells the transit provider's network to drop all traffic directed to a given IP address (most often a /32) before it enters the customer's link. This is a blunt solution, since it also cuts off legitimate traffic to the same address, but it is effective where FlowSpec physically has no chance of working.

LiveShield generates RTBH rules automatically, based on the same detection thresholds that are responsible for FlowSpec, and announces them over a BGP session configured with the operator's router. What is crucial, however, is that the effectiveness of this mechanism depends on what happens next, that is, on how quickly and in what way the transit provider reacts to these announcements.

Since the final effectiveness of RTBH depends on the upstream, the advantage of an anti-DDoS system is decided at the stage the operator actually controls: how quickly the attack is detected and how quickly the correct RTBH rule reaches the transit provider. The shorter this time, the shorter the window in which the link remains saturated before the upstream can react.

LiveShield analyzes traffic packet by packet, in real time and in memory, instead of relying on aggregated NetFlow or sFlow data, which by nature provide a picture of the situation with a delay of tens of seconds to several minutes. In practice this means detecting the attack and generating the first protective rules within single seconds of its start, rather than after the fact, when the link has already been saturated for a long time.

The second element that shortens response time is automation. The event pipeline mechanism makes it possible to define in advance exactly what should happen when an attack exceeding a given threshold is detected: generating and announcing RTBH, notifying the NOC team, calling an external script (triggering, for example, scrubbing) or recording the event in a ticketing system. The operator does not react manually after the fact but has a ready, previously tested scenario that runs by itself.

For operators who already have (or are planning) a contract with an external scrubbing center, LiveShield's event pipeline makes it possible to tie attack detection to an automatic redirection of traffic to such a center, instead of only blocking the address via RTBH. This is not a ready-made out-of-the-box integration: it requires configuration for the specific network topology and the specific scrubbing provider, but the event pipeline functionality allows it, so LiveShield can serve as the detection and decision layer even in an architecture that ultimately does not end with RTBH.

This is a distinction worth understanding before deploying any anti-DDoS system, not just LiveShield: the local system is responsible for detecting the attack and generating a correct RTBH rule. How quickly that rule actually cuts off traffic before it enters the link depends on the configuration and policy of the transit provider, not on the anti-DDoS system.

In practice, this means that before deploying protection against volumetric attacks exceeding link capacity, the ISP should establish directly with its transit provider:

Without this conversation with the upstream, the anti-DDoS system may work correctly, detecting the attack and generating the rule at the right time, and still fail to protect the link if the upstream itself does not honor the announcements it receives or reacts to them too slowly.

There is no local alternative. If the attack volume exceeds the uplink capacity, the only way is to cut off traffic closer to the source, that is, on the transit provider's side or even further away, at the next providers in the chain. Solutions operating only locally at the customer, regardless of the vendor and filtering mechanism, are physically unable to process traffic that will not fit on the link.

That is why, when designing anti-DDoS protection for ISP networks, it is worth treating RTBH to the upstream from the start as an integral part of the architecture, and not as a backup mechanism triggered only in exceptional cases.

A DDoS attack exceeding the uplink capacity is a scenario in which local traffic filtering (FlowSpec) stops being enough, because the link is saturated before the traffic reaches the filtering device. The only effective mechanism in this situation is RTBH announced to the transit provider, and its real effectiveness depends on that provider's policy and speed of reaction. That is why arrangements with the transit provider should be part of the preparation for deploying anti-DDoS protection, and not an element skipped until the first large attack.

Will FlowSpec stop an attack larger than my uplink? No. FlowSpec is announced on the customer's routers, which are already behind the uplink. If the attack saturates that link, part of the traffic will never reach the filtering rule.

What is RTBH and how does it differ from FlowSpec? RTBH (Remotely Triggered Black Hole) is a mechanism that cuts off all traffic directed to a given IP address, announced to the transit provider, so that traffic is dropped before it enters the customer's link. Unlike FlowSpec, it does not filter precisely: it blocks the address entirely, together with legitimate traffic.

Does every transit provider honor RTBH announcements? It depends on the specific transit provider and must be established directly with them, including the accepted BGP community and the reaction time to the announcement.