A DDoS attack can saturate a connection, overload network components or exhaust a particular service. From a user's perspective, the outcome is similar: the application becomes slow or unavailable.
The required protection is not identical for every attack. A design focused only on bandwidth can overlook packet-processing limits or service-specific behaviour. Detection, traffic steering, mitigation and recovery therefore need to be designed as a connected system.
Thunder TPS and A10 Defend
Thunder TPS remains a name encountered in technical documentation and existing deployments. A10 presents its current DDoS offering under A10 Defend, including detection, mitigation and orchestration components. See the current product overview and product documentation.
A product name alone is not a deployment specification. Hardware, software release, licences, available capacity and deployment mode determine what is usable in a particular environment. Design against those facts rather than a single headline performance figure.
Detection needs a service baseline
An increase in traffic can indicate an attack or a legitimate event: a public campaign, software release or large number of simultaneous users.
A useful baseline describes more than average bandwidth. Depending on the service, bits per second, packets per second, new connections and protocol distribution may all matter.
A10 describes behavioural profiling and anomaly detection as parts of its DDoS offering. Their operational use still requires decisions: how normal traffic is established, which deviations trigger action and how expected peaks are handled.
A baseline learned from an inappropriate starting condition will not provide a reliable interpretation of later traffic. Review the observation period and include the application owners when deciding what legitimate variation looks like.
Inline and reactive protection have different dependencies
With inline mitigation, normal traffic traverses the protection path. In a reactive design, detected traffic is steered into a mitigation path after an event is recognised.
A10's historical Thunder TPS Deployment Guide describes asymmetric reactive, asymmetric proactive and symmetric modes. Current product material also describes inline and out-of-band options. Use the guide to understand the architecture, not as a substitute for the configuration reference of a current release.
A reactive design must test activation of the path as well as filtering. How is traffic redirected? Where does cleaned traffic return? What happens if the detection or routing component is unavailable?
For inline designs, normal-path capacity and continuity deserve equal attention. Protection should not become an unexplained dependency in the service chain.
Bandwidth is only one capacity measure
Identify where the first bottleneck can occur. A link may become saturated before traffic reaches a local mitigation device. Many small packets may stress a component even when the bandwidth figure looks less dramatic.
Capacity planning should assess realistic traffic profiles across the complete chain. A datasheet value does not prove identical performance for every combination of attack traffic and legitimate requests.
A10 publishes DDoS defence test material that assesses attack types and legitimate traffic handling. The relevant lesson is to choose an acceptance profile that reflects the protected services, rather than assuming that one throughput number answers every design question.
Measure legitimate service availability
Blocked-packet counters tell only part of the story. The application can remain unusable if legitimate requests are affected or response time deteriorates.
A controlled test should measure attack handling and representative user behaviour at the same time. For DNS, that may be successful processing of legitimate queries. For a web application, it can be a representative transaction.
Define how unintended filtering is recognised and investigated. Automated action still needs useful visibility and an operational recovery path. Document what staff should inspect and when they should escalate.
Test the end of the attack
Recovery belongs in acceptance testing. Observe whether traffic is handled correctly after the attack, temporary actions are withdrawn appropriately and the service remains stable.
Record detection, activation, usable service, attack termination and return to the normal state. These milestones provide a more meaningful result than mitigation counters alone.
DDoS protection should ultimately be assessed against its purpose: preserving useful service availability while the environment is under pressure, then returning predictably to normal operation.