LiveShield Redundancy: What Happens When a Worker, an Analyser or an Entire Location Fails?

The LiveShield worker is required separately at each location where traffic is received from the upstream, because it analyzes a local copy of the traffic taken via a port mirror (SPAN) or an optical TAP. The analyser and manager, the modules responsible for mitigation decisions and configuration, can, however, be centralized.

This question arises in every network that has more than one edge location with independent sessions to transit providers, and LiveShield's architecture has an unambiguous answer to it, following directly from how attack detection works.

The LiveShield worker analyzes the traffic that physically reaches it, that is, a copy of the traffic from a local port mirror or TAP link connected to the edge router or switch at a given location. If a network has two independent locations with separate BGP sessions to upstreams, each of them needs its own worker connected to the local traffic source. A worker cannot be "sent" to a remote location over the network, because it would then have to receive raw traffic over a WAN link, which is inefficient and in practice unfeasible at higher throughputs.

After analysis, the worker sends only aggregated statistical data to the analyser, not raw traffic, over an ordinary TCP connection on the server's management interface. This channel requires on the order of single megabits per second, so it can be run even between locations without loading production links.

If a separate, fully independent worker-analyser-manager set is deployed at each location, each of these instances calculates detection thresholds solely on the basis of the traffic it sees locally. This opens a detection gap: an attacker can split the attack volume between two locations so that neither of them alone exceeds the configured threshold, even though the combined traffic at both entry points to the network is already an attack.

Example: if the UDP detection threshold is set to 5 Gb/s at both locations separately, an attacker sending 3 Gb/s through each of them (6 Gb/s in total) will not be detected at either, even though the real attack exceeds the assumed threshold.

Sending aggregated data from all workers to one shared analyser solves this problem: the analyser sees the full picture of traffic from all locations at once and makes decisions based on the actual sum of traffic, not a local slice of it. An additional benefit is that the operator maintains one threshold configuration instead of several parallel ones that would have to be synchronized manually with every change.

LiveShield operates in an architecture outside the production traffic path (off-path): the worker analyzes a copy of traffic taken from the mirror, not traffic passing physically through the device. As a result, a worker failure does not interrupt production traffic at the given location. Only the ability to detect and respond to new attacks is lost until the worker is restored.

This is a fundamental difference compared with inline solutions, where the failure of a filtering device can translate directly into an interruption of customer traffic.

LiveShield redundancy in a multi-location network rests on two principles: the worker must run separately at each location, because it needs a local traffic source, while the analyser and manager should be centralized so that detection is based on the full picture of traffic from all locations at once. Thanks to the off-path architecture, a worker failure does not interrupt production traffic. It only limits the ability to detect new attacks until it is restored.

Is one LiveShield worker enough for a network with two locations? No, if both locations have independent BGP sessions to upstreams and receive traffic separately: each of them requires its own worker connected to the local traffic mirror.

Do the analyser and manager have to be installed separately at each location? This is not recommended. One shared analyser for all locations gives a full picture of traffic and improves detection accuracy compared with separate, independent configurations.

Does a worker failure interrupt customer traffic? No. LiveShield works in an off-path architecture, analyzing a copy of traffic from a port mirror or TAP link. A worker failure limits the ability to detect new attacks but does not affect production traffic passing through the network.