Migrating to LiveShield from Another Anti-DDoS System
Migrating to LiveShield from Another Anti-DDoS System
Conversations about changing an anti-DDoS system almost always start the same way: the current solution does not meet expectations (detection is too slow, distributed attacks go unnoticed, configuration requires constant manual work), but the operator hesitates over migration. There are two reasons, and both sound reasonable. First: "we have a paid license until next year." Second, more important: "we cannot afford a period without protection during the transition."
Both problems can be solved. And the second, in the case of LiveShield, essentially does not exist, which follows directly from the system's architecture.
Why migration does not require switching off the current protection
LiveShield analyzes a copy of traffic delivered by a mirror from edge routers or switches (port mirror / SPAN). The system does not sit in the production traffic path and changes nothing there. The only active element is BGP announcements, which are switched on deliberately, at the end of the process.
This has a practical consequence: LiveShield can run in parallel with the existing system on the same traffic. It is enough to direct the mirror to both systems at once. The existing protection keeps working without any changes, and LiveShield sees exactly the same attacks in the meantime, so you can compare live what one system detects and what the other does.
Migration stops being a leap into the deep end. It becomes a controlled process in which the old system is switched off only once the new one has proven its effectiveness on your network's real traffic.
What migration looks like in stages
A typical course of a parallel deployment, based on our practice with ISPs:
Important: this is an example plan. Every ISP is different, and the migration plan is always prepared according to the Operator's needs.
- Infrastructure preparation. A server (or servers) with a network card of adequate throughput, Debian 13, access via the management network. A mirror of incoming traffic directed to a server port, in parallel with the data source of the current system. At this stage nothing changes in the working protection.
- Passive operation and detection comparison. LiveShield analyzes traffic and detects attacks but announces no rules: BGP sessions can be established and verified, but mitigation remains off. This is the period in which the NOC team watches both systems side by side: detection times, detected vectors, attacks visible in only one of the systems. At the same time, per-IP and per-subnet thresholds are tuned to the specifics of the network.
- Gradual takeover of mitigation. We usually start with blackholing, then FlowSpec is enabled on routers that support it. This can be done per prefix or per customer group: part of the network is already protected by LiveShield, part still by the old system.
- Switching off the previous system. This happens only when LiveShield has taken over full mitigation and gone through a trial period on real incidents. No big switchover day and no maintenance window.
We can carry out the entire configuration on our side, including migrating router configurations if edge hardware is also being replaced at the same time.
LiveShield migration
What a comparison on live traffic shows
Parallel operation has one more advantage: instead of comparing systems based on marketing materials, you compare them on attacks in your own network.
An example from one such parallel installation: a multi-vector attack (IP Fragments + DNS + UDP flood) with a volume of 6.5 Gbps and 700 kpps. LiveShield detected the attack and applied the first filtering rule in the same second. The competing system running alongside detected the attack 4 seconds later and introduced its first rule 18 seconds after LiveShield's detection. The third vector, despite correct configuration, it did not filter at all.
A dozen or so seconds of difference sounds innocent, but it is precisely in the first seconds of an attack that it is decided whether customers feel the incident. And a vector the system did not filter at all is the difference between "attack mitigated" and phone calls to the support desk.
The license question: double costs are smaller than they seem
What remains is the argument "we have a paid license." In practice it is rarely a blocker, for two reasons.
First, LiveShield's licensing model is based solely on incoming traffic, with no fees for the number of sensors, filters, interfaces or locations. You do not have to adapt the network architecture to the licensing model or buy additional components to get full functionality: detection, filtering, FlowSpec, blackholing and reporting are in one license.
Second, the period of overlapping licenses can be limited to a minimum: the parallel deployment is planned so that the takeover of mitigation coincides with the end of the current contract. The old system lives out its term as a safeguard, while the new one is tuned and verified in the meantime. As a result, instead of double costs, the operator gets something they normally do not have: a practically free trial period on their own production traffic.
Where to start
If you are considering changing your anti-DDoS system, the simplest first step requires no purchasing decisions: check whether you can direct a traffic mirror to an additional port, and write to us at office@liveshield.net. We will determine the hardware requirements for your traffic volume and propose a parallel deployment plan matched to the date of your current contract.
