On this page
Key points
- Draw both traffic directionsThe incoming path, filtered delivery and application return path can have different constraints.
- Separate observation from filteringA flow collector measures traffic; another component must perform any packet enforcement.
- Include maintenance and failureA second node is useful only when routing, capacity and operating procedures support the intended fallback.
Start with the path traffic really takes
A useful DDoS design begins with the protected destinations, their upstream paths and the first resource that can be exhausted. Draw the normal incoming path, the path during mitigation and the return path. Mark every constrained handoff and identify who is allowed to announce, divert or withdraw each prefix.
The design must explain what happens to a legitimate request from arrival to application response. A diagram that stops at a scrubbing cloud misses the receiving link, tunnel, firewall and server that still have to handle the residual traffic.
Keep four responsibilities distinct
These functions may share a product, but they still need separate proof. Seeing a route in BGP does not by itself demonstrate that a filter is enforcing the intended rule. Receiving flow telemetry does not mean that the collector is in the packet path.
| Function | Output or action | Acceptance evidence |
|---|---|---|
| Observe and detect | Samples, counters, alerts or a candidate incident. | Known observation point, sampling, delay and missing-data behavior. |
| Decide and steer | An authorized route or policy change. | Scope, validation, convergence and a withdrawal procedure. |
| Inspect and filter | Packet forwarding, dropping or supported limiting. | Installed policy, decision counters and legitimate service success. |
| Deliver and serve | Filtered traffic reaches the application and responses return. | Capacity, MTU, routing, latency and application-level checks. |
Choose placement from the actual bottleneck
Upstream mitigation is relevant when offered traffic can exhaust the customer access path. Local filtering is relevant when the operator has sufficient incoming capacity and wants control over packet decisions on its own equipment. A hybrid design can combine the two, but adds policy and failure interactions that need an owner.
An application proxy may suit a supported protocol and delivery model. It is not interchangeable with protection for an arbitrary routed prefix. Likewise, an HTTP control does not cover every UDP or TCP service. List the applications and address families explicitly instead of treating “Layer 7” as a universal capability.
Always-on and on-demand have different tests
In an always-on design, normal traffic continuously uses the protection path. Validate everyday latency, return routing, maintenance behavior and the capacity of that path. In an on-demand design, also measure detection, decision and route-change delays; the transition can affect sessions even if the eventual path works.
Use hysteresis and an explicit recovery procedure to prevent repeated activation and withdrawal around a threshold. Missing or stale telemetry needs a defined response. An operator must know whether the current route stays in place, is withdrawn or requires intervention; do not assume every controller behaves the same way.
Peeryx Flow Collector is an out-of-path observer and diversion coordinator, not an inline packet filter. Its automatic diversion scope is authorized IPv4 /24 prefixes. Eligibility, routing permissions and the protected service must be verified separately; this does not imply automatic IPv6 diversion.
Example: upstream reduction with a local policy layer
Suppose an operator has a 10 Gbit/s receiving handoff and applications behind a local firewall. If incoming traffic exceeds that handoff, adding a more powerful filter behind it does not move the loss point. An upstream protection path can address that constraint, while the local layer continues enforcing the application’s access policy.
If delivery uses GRE, record the outer path, effective inner MTU and return routes. Test application transfers large enough to reveal MTU problems; a small ping is insufficient. Stateful controls may require both directions to traverse a compatible state path. This is a design example, not a promise of interruption-free diversion.
Make the handover testable
Prove authority and reachability
Confirm prefix ownership or authorization, accepted announcements, next hops and every required address family. Check normal and protected paths from independent observation points.
Qualify capacity under failure
Measure the traffic mix with the intended features enabled. Account for distribution skew, receiving links and the loss of the node or uplink the design claims to tolerate.
Exercise the application
Test new and established sessions, relevant protocols, MTU-sensitive transfers and return traffic. Observe legitimate success alongside mitigation counters.
Rehearse recovery
In an isolated environment or agreed maintenance window, test the specified process, link or node fault. Record convergence, session impact, rollback and access to management.
A backup label is not a failover result
- Two tunnels on one physical router do not provide independence from that router.
- An established backup BGP session does not prove that usable routes and forwarding are selected when the primary disappears.
- A bypass can preserve connectivity while sending traffic around the filter; check the resulting protection state.
- Two equal-speed links do not guarantee an even traffic split or double the capacity of one flow.
- A failover that works for stateless packets may still interrupt sessions that depend on shared state.
Keep a short operating record
The delivery record should contain the topology, protected scope, capacity assumptions, acceptance results, alert ownership and reversal procedure. Keep planned behavior separate from observed results. Recheck the relevant tests after a routing, software or physical-path change.
Questions and answers
Does a collector filter the traffic it reports?
Not necessarily. Flow telemetry can be exported to an observer outside the forwarding path. Identify the separate component that actually inspects or drops packets.
Does a second tunnel guarantee router redundancy?
No. Check physical hosts, underlay paths, selected routes and the tested failure scenario. Two tunnels can share the same failure point.
Can a working ping validate the entire design?
No. It confirms only a narrow reachability test. Validate relevant packet sizes, application behavior, traffic load, return paths and the intended failure procedure.
