On this page
Key points
- Observe the whole chainRouting, received traffic, policy counters and application results should describe the same time window.
- Confirm the effect of a changeAn accepted request or advertised rule is not enough to prove that the data path changed.
- Plan withdrawal as well as activationTemporary protection needs an owner, a review condition and a controlled route back to normal operation.
1. Direct authorized traffic to the mitigation path
The first task is to make the relevant public traffic traverse the intended protection infrastructure. In a routed deployment this can involve agreed prefix announcements and routing policy. In a service-specific deployment the public endpoint may already lead through a protected entry point. The mechanism must match what the customer and provider are authorized to control.
Always-on and on-demand designs have different transitions. For on-demand protection, identify who requests activation, which destinations are eligible, how the change is confirmed and who can withdraw it. Do not equate an API request being accepted with routes being selected or traffic arriving at the filtering path.
Observe the routing and received traffic for the same destinations and time interval. Check the return path separately. A tunnel transports packets between endpoints, but by itself does not establish that the desired Internet traffic has been attracted.
2. Build an evidence-based view of the traffic
Compare traffic volume, packet rate, protocol distribution, lengths and connection behavior where the deployment exposes those observations. Keep timestamps, direction, destination and measurement boundary with each figure. A sampled flow record and a full packet counter are not equivalent evidence.
Use an appropriate normal-traffic reference. A popular event, client retries and an attack can all increase activity, so a threshold crossing should be interpreted with context. Identify the affected service and whether existing sessions, new sessions or only a subset of client networks are failing.
Telemetry describes what a sensor can see. Missing or delayed data is not evidence of absent traffic. Record blind spots and avoid interpreting one quiet sensor as proof that the incident has ended.
3. Apply a policy whose scope can be checked
A mitigation decision should identify the target, match conditions, intended action, owner and review condition. The aim is to reduce harmful load while keeping the required legitimate exchanges usable. More discarded packets do not, by themselves, demonstrate a better policy.
Control-plane distribution and enforcement are separate observations. BGP FlowSpec distributes traffic-matching information and actions, but receiver policy and implementation determine acceptance and application. Inspect the installed rule and relevant counters rather than assuming that an advertised rule is active everywhere.
Use changes proportionate to the identified problem and retain an approved rollback. A broad block may reduce load while also removing a legitimate service. If the local filtering path is itself constrained, coordinate upstream relief according to the agreed service rather than assuming software can absorb unlimited ingress.
4. Deliver the retained traffic over a usable path
Confirm that traffic leaving filtering reaches the intended destination through the delivered handoff. Check addressing, next hop, encapsulation and the expected return route. A successful forwarding counter at one device does not prove that the remote application completed an exchange.
Validate the MTU required by each primary and recovery path. Larger application exchanges can expose problems that small probes miss. TCP, UDP and application-specific behavior need suitable acceptance checks; a TCP-MSS adjustment is not a universal solution for every protocol.
Where an origin is intended to be reachable only through a protected entry point, verify the approved access boundary as part of delivery. A changed public name does not remove all other routes to an exposed origin. Coordinate this with the owner of the destination network.
5. Keep the incident record useful to both teams
Use a shared time window when comparing provider observations and customer symptoms. Record affected destinations, active policies, routing changes and the latest successful application check. Separate direct observations from hypotheses so the next engineer can reproduce the reasoning.
Keep an agreed communication path that does not depend entirely on the impaired service. Define who may approve a route or policy change and who can verify the application. A monitoring status and a contractual response commitment are different things; use the actual support terms.
| Stage | Evidence of progress | A result that is insufficient alone |
|---|---|---|
| Attraction | Expected route selection and traffic at the intended ingress | Activation request accepted |
| Classification | Matched counters and symptoms for the same interval | A single threshold alarm |
| Enforcement | Accepted or installed policy with relevant effect counters | Rule advertised by a controller |
| Delivery | Application exchange over the intended handoff and return path | Tunnel or BGP session up |
| Recovery | Stable application checks and reviewed temporary controls | Traffic graph back near baseline |
6. Withdraw temporary controls deliberately
Agree on a review condition for temporary routing and filtering changes. Keep visibility while restoring the normal path, because the return transition can expose a different failure or a recurring attack. Record what remains active and why.
Check application recovery from representative affected networks as well as a working reference. Test new sessions separately from established ones where the service requires it. Retire obsolete restrictions through an authorized sequence rather than deleting every emergency control at once.
Rehearse the operating process before depending on it
An acceptance exercise can verify permissions, contact paths, routing observations, a controlled transition and a normal application exchange. It need not generate attack traffic. Define the scope, stop condition and recovery owner in advance, and protect unrelated services from the exercise.
Capacity benchmarks require a separate isolated test plan with stated hardware, software, traffic and acceptance criteria. Do not present a successful activation exercise as a Gbit/s or Mpps benchmark. Likewise, do not promise that a measured single-device result covers untested upstream or failover dependencies.
Questions about the operating chain
Does an active tunnel mean protection is working end to end?
No. Confirm traffic attraction, relevant policy, delivery and a successful application exchange. Tunnel and BGP states are useful observations with a narrower scope.
Does Flow Collector perform inline packet filtering?
No. The published Peeryx Flow Collector scope is telemetry, detection and controlled diversion for eligible, authorized prefixes. Inline filtering is a separate role in the protection path.
When can an incident be considered recovered?
When the agreed service checks succeed, the remaining controls are understood and the normal or approved temporary path is stable. A bandwidth chart alone does not establish those conditions.
