On this page
Key points
- A complete delivery chainTraffic must reach filtering, legitimate exchanges must survive the policy, and the result must reach the application.
- Separate the capacity figuresUpstream connectivity, local packet processing and clean-traffic delivery constrain different parts of the service.
- Choose who operates itBuying protected transit and licensing software for your own equipment assign different responsibilities.
A filtering location is only part of the service
A DDoS scrubbing center is an infrastructure through which traffic is directed for attack mitigation before delivery to a protected destination. It combines network connectivity, traffic handling, filtering policy and an onward path. The protected destination might be a routed customer network, a hosting platform or an individual public service.
The objective is to keep legitimate service exchanges usable while reducing harmful traffic. “Clean traffic” describes the intended output of that process; it does not certify that every delivered packet is harmless or that the application cannot fail for another reason. Network and application controls still need an agreed division of work.
Do not confuse the filtering location with the whole protection service. If traffic cannot reach it, if policy removes legitimate requests, or if the onward path is unusable, a filtering server that is healthy internally does not establish service availability.
Filtering must sit before the resource it is meant to relieve
A volumetric attack can exhaust a link before the target host receives the packets. In that case, local application or host rules do not restore the capacity already consumed upstream. A remote filtering path can help only if the traffic is actually carried to that path before the constrained resource.
Other incidents first exhaust packet handling, connection state or an application function. Large upstream bandwidth does not automatically solve those limits. The design should state which resources it protects and how remaining traffic is handled at the origin.
Separate traffic attraction from clean-traffic delivery
Attraction determines where public traffic enters the mitigation path. Delivery determines how the retained traffic reaches the real destination. BGP routing, protected addressing and a service-specific proxy are possible parts of different designs; they are not interchangeable purchases. A tunnel alone does not announce a prefix to the Internet.
For a routed network, confirm authorized prefixes, announcement policy, address families and the required return path. For an individual service, confirm the public entry point, origin reachability, ports and application compatibility. The relevant delivery might use a tunnel, a physical handoff or another explicitly supported mechanism.
Keep primary and recovery paths in the same design record. Different MTUs, shared transport dependencies or an unexpected static route can affect recovery even when two BGP sessions appear healthy. Test the delivered architecture against a real application reference.
Choose between a provider service and an operated filtering stack
With protected transit, the provider supplies a defined network service and the customer integrates its delivery. Confirm what capacity, activation behavior, filtering scope and support are actually included. A provider-wide network figure is not a reserved clean-traffic port or an unlimited commitment for one customer.
With software such as Defense Fabric, the operator supplies compatible servers and a usable network architecture. Software licensing does not provide the upstream links, routing permissions, physical deployment or staff needed to operate a scrubbing center. This model can fit teams that want control of their own equipment and can own those responsibilities.
A combined architecture may place provider filtering before locally operated controls. Define the handoff and residual workload instead of adding the two advertised capacities together. Compatibility, operational responsibilities and acceptance criteria matter more than calling the design “hybrid”.
Ask for evidence that matches the service you need
Compare offers with the same scope and accounting boundaries. A shared network total, one device benchmark and a port speed answer different questions. Ask which measurements exist, under what configuration, and which figures are published service limits or design assumptions rather than measurements.
| Buying question | Evidence to request | What the answer must distinguish |
|---|---|---|
| How does traffic reach filtering? | An authorized attraction and withdrawal plan | Normal routing, attack routing and rollback |
| What can the path carry? | Limits for ingress, packet processing and onward delivery | Shared capacity, reserved capacity and tested performance |
| What is filtered? | Supported protocols, policy scope and legitimate-traffic checks | Network protection and application-specific controls |
| How is traffic delivered? | Addressing, encapsulation, MTU and return-path requirements | Main path, recovery path and shared dependencies |
| Who operates an incident? | Contacts, visibility, change authority and agreed support terms | Observed status and contractual commitments |
Match the architecture to what you control
An ISP or hosting operator may control prefix announcements and several network handoffs. Its review should cover routing authority, downstream customers, traffic distribution and failure domains. A dedicated-server customer at a third-party host may control only the server and a permitted tunnel endpoint. Provider policies and direct origin exposure then become essential constraints.
A game service adds its own protocol and player-journey requirements. A general network filter is not automatically a compatible application proxy. Identify the edition, public listener, backend path and required features before selecting a gaming-specific offer.
Do not buy a capacity number without its boundaries
- Keep shared upstream capacity separate from local filtering measurements and a customer delivery port.
- Check false-positive handling and application recovery as well as the number of dropped packets.
- Do not assume that software licensing includes transit, compatible hardware or an operated network service.
- Do not treat a second session, an online dashboard or a short ping as proof of complete failover.
- Record who may change routing and policy, what happens on failure and how the previous state is restored.
Questions about scrubbing-center services
Does a scrubbing center guarantee that an application remains available?
No universal guarantee follows from the architecture. Capacity, routing, filtering policy, delivery and the application all matter. Review the actual service scope and contractual commitments.
Can I build a scrubbing center by buying a software licence?
A licence can provide one component. You still need compatible equipment, network capacity, routing and delivery, monitoring, operational ownership and an acceptance process.
What is the next step after choosing a model?
Document the traffic path and responsibilities, confirm delivery conditions and agree on acceptance checks. The operating-chain guide explains what to observe from attraction through recovery.
