LiveShield and Scrubbing Center - how local DDoS protection and a scrubbing center can complement each other

LiveShield and a scrubbing center are not solutions an operator has to choose between once and for all - they are two different layers of DDoS protection that suit different situations and can work together: LiveShield filters most attacks locally, in real time and without additional latency, while the scrubbing center takes over the cases where local filtering stops being enough - for example, an attack exceeding uplink capacity, or one requiring deeper, stateful traffic analysis.

This question comes up increasingly often among ISP operators who are already considering or building their own scrubbing center, and are wondering whether that means giving up local protection, or rather extending it.

A scrubbing center is external infrastructure to which, in the event of an attack, traffic directed at the targeted address is redirected - there it is cleaned of attack packets, and only the "clean" traffic returns to the destination network. On-premise protection, such as LiveShield, works the other way around: analysis and filtering happen locally, on the operator's own hardware, without redirecting traffic outside the network.

Each of these models has a different cost and latency profile. Redirecting traffic to a scrubbing center adds an extra hop to the path (routing through external infrastructure), which for latency-sensitive services can matter even beyond the duration of the attack, if the redirection is permanent. Local filtering does not introduce this extra step - legitimate traffic follows its normal path, and is only modified where and when an attack is actually detected.

On the other hand, a scrubbing center has a resource a single local operator typically does not - substantially larger, aggregated bandwidth capable of absorbing an attack that exceeds the capacity of a single uplink.

The vast majority of DDoS attacks ISP operators face don't require redirecting traffic outside the network - precise, fast local filtering is enough, which LiveShield delivers through BGP FlowSpec, backed up by blackholing (RTBH) when local filtering stops being sufficient for a given link. Routing every attack, even a small one, to an external scrubbing center would be inefficient - it adds latency and cost exactly where a local FlowSpec rule would handle it just as effectively, and faster.

A scrubbing center makes sense as a second layer of protection, triggered selectively, for the minority of cases where local filtering genuinely isn't enough - primarily an attack exceeding uplink capacity, and attacks requiring stateful traffic analysis beyond what FlowSpec rules on the operator's edge hardware can achieve.

LiveShield does not operate in a scrubbing-center model by default - it does not redirect traffic outside the network for cleaning as standard, but mitigates attacks locally, on the operator's own edge routers, using FlowSpec and RTBH. The system does, however, provide an event pipeline mechanism - the ability to trigger arbitrary actions and scripts in response to a detected attack.

This means that if an operator has an agreement with an external scrubbing center, LiveShield can be configured so that under defined conditions - for example, when an attack exceeds a set traffic threshold that local filtering can no longer handle effectively - it automatically triggers redirection of the relevant prefix to that scrubbing center. This is not an out-of-the-box integration for any given scrubbing provider - it requires configuration tailored to the specific environment and the specific partner agreement - but the event pipeline functionality fully supports it.

In practice, this creates a division of roles: LiveShield is responsible for detecting the attack, making the first, fast mitigation decision and, if needed, sending the signal onward, while the scrubbing center only steps in once it's actually needed, rather than being the first and only point of handling for all traffic.

An architecture combining local filtering with a backup channel to a scrubbing center makes the most sense where an operator wants to retain full control and minimal latency for normal traffic and most attacks, while also accounting for the scenario of an attack that exceeds the capacity of its own uplink connections. This is exactly the situation many small and mid-sized ISP operators find themselves in today, faced with the growing scale of volumetric attacks - which is also where initiatives to build shared, community scrubbing centers at internet exchange points come from.

For an operator just starting to build DDoS protection, the sensible sequence is usually: first, local, fast filtering (FlowSpec/RTBH) covering the vast majority of real attacks, and only later, as needs and scale grow, extending this with a scrubbing center agreement as a safeguard against attacks exceeding local link capacity.

LiveShield and a scrubbing center do not compete with each other - they cover different layers of DDoS protection: local, fast FlowSpec/RTBH filtering handles the vast majority of attacks without additional latency or redirection cost, while the scrubbing center serves as a reserve layer for attacks exceeding what local infrastructure can handle. LiveShield's event pipeline mechanism allows both approaches to be combined into one coherent architecture - automatic redirection to a scrubbing center triggered only when actually needed, rather than as the default path for all traffic.

Does LiveShield replace a scrubbing center? No, and that isn't its role. LiveShield mitigates attacks locally by default, on the operator's edge routers, through FlowSpec and RTBH - a different, complementary model to a scrubbing center, not a substitute for it in every scenario.

Can LiveShield be connected to an external scrubbing center? Yes. The event pipeline mechanism allows automatic traffic redirection to an external scrubbing center to be configured in response to a detected attack, if the operator has such an agreement - this requires configuration tailored to the specific environment.

When is it worth considering a scrubbing center alongside local DDoS protection? Primarily when an operator needs to account for the scenario of an attack exceeding its own uplink capacity - in that situation local filtering physically cannot relieve the link, and the solution is either RTBH to the upstream provider or redirection to a scrubbing center.

Should every attack be routed to a scrubbing center? No. The vast majority of DDoS attacks can be handled effectively and faster by local FlowSpec filtering, without the added latency of redirecting traffic outside the network. A scrubbing center makes sense as a selective reserve layer, not as the default path for all traffic.