Detection Policies and Traffic Analytics
Configure BPS, PPS, and FPS policies, tune learned baselines, classify traffic, and interpret DDoS analytics.
On this page
DDoS Protection evaluates current traffic against absolute thresholds and a learned clean-traffic baseline. Use Detection for policy configuration and the analytics workspaces for investigation context.
Understand the three signals
| Signal | What it measures | Useful for |
|---|---|---|
| BPS | Bits per second | Volumetric saturation and sudden bandwidth growth. |
| PPS | Packets per second | Packet floods that may stress routers or services before a link is full. |
| FPS | Flows per second | Connection or flow churn that can pressure state tables and collectors. |
Create detection policies
- Open DDoS Protection → Detection.
- Apply the monitored-capacity preset or create a custom policy.
- Select the protected scope and metric.
- Set the absolute threshold, baseline multiplier, evaluation window, and severity.
- Enable at least one policy for each of BPS, PPS, and FPS before activation.
The capacity preset is a starting point, not a permanent answer. Tune policies after the learning window includes representative busy hours, quiet periods, billing events, backups, and known content peaks.
Tune without hiding incidents
- Use a longer evaluation window for short legitimate bursts, not simply a much higher threshold.
- Keep absolute thresholds as a safety floor while the baseline is immature.
- Compare the same weekday and hour when traffic has strong business cycles.
- Adjust one variable at a time and retain incident history for review.
- Use separate policies when infrastructure ranges and subscriber pools have different normal profiles.
A low alert count is not proof of safety. Always confirm that telemetry is current, the intended prefixes are covered, and all three signals have enabled policies.
Use the analytics workspaces
| Workspace | Question it answers |
|---|---|
| Traffic | When did BPS, PPS, or FPS change across the selected 1-hour to 7-day period? |
| Destinations | Which content, exchange, transit, or exporter direction accounts for observed traffic? |
| Sources | Which source addresses and public origin ASNs contribute the most traffic? |
| Targets | Which protected destinations receive the largest bandwidth, packet, flow, or traffic share? |
| Protocols | Which IP protocols and destination ports shape the event? |
| Connectivity | What route visibility, AS path, RPKI, and exchange context is currently observable? |
Classify local and upstream traffic
Destinations identifies public content origins such as Meta, Google, TikTok, Cloudflare, and AWS from observed ASN data. Local CDN, IIG, BDIX, and uplink paths are ISP-specific. Open Classify local CDN, IIG, BDIX and uplink traffic and add the exact ASN or CIDR supplied by the network team.
A tenant CIDR match takes precedence over a tenant ASN and then a built-in public service ASN. Exporter visibility reports traffic received per configured source; it identifies a physical circuit only when the operator has labelled that path accurately.
Policy review checklist
- Every protected range is covered by intentional BPS, PPS, and FPS policies.
- Thresholds fit monitored capacity and known legitimate peaks.
- The evaluation window avoids single-sample noise without delaying critical detection.
- Severity matches the operational response and notification policy.
- Traffic classifications use network-team-confirmed ASN or CIDR values.
When an alert opens, continue with Investigate a DDoS attack.