DDoS Detection Thresholds: pps vs bps, Hysteresis, Tuning

DDoS detection thresholds work best when packets per second (pps) is the primary trigger per destination IP, bits per second (bps) is a secondary guard, and a separate per-prefix limit catches attacks spread across many hosts. Add hysteresis (a lower clear threshold, a trigger duration and a minimum hold time) so one attack does not produce a dozen alerts and a flapping blackhole.

This guide covers how to pick the numbers from your own traffic, how to structure host and prefix limits, and how to keep on-call engineers from learning to ignore alerts.

pps vs bps: which one should trigger?

Both. They catch different attacks.

A 1 Gbps stream of minimum-size Ethernet frames is roughly 1.49 Mpps on the wire. A customer on a 1 Gbps port can be knocked offline by a flood that barely registers on a bps graph, while a firewall or a stateful router falls over on pps. If you only alert on bps, you will miss the attacks that hurt small servers and stateful devices most.

Practical rule: set the pps threshold from what your busiest legitimate host does, and set the bps threshold close to the capacity of the customer's port or your upstream link. The bps threshold is a capacity guard. The pps threshold is the real detector.

Per-host vs per-prefix thresholds

Most attacks target one IP. Carpet bombing spreads traffic across a whole /24 so that no single host crosses a per-host threshold. You need both layers.

• Per-host: Group hosts by role and give each group its own limits. A DNS resolver, a game server, a shared web host and an idle VPS should not share one number.
• Per-prefix: Sum traffic toward each announced prefix (for example 192.0.2.0/24) and alert when the aggregate exceeds a limit well above normal, even if every individual host is under its limit.
• Global defaults: Keep a conservative catch-all for IPs not in any group, so new customers are never unmonitored.

A reasonable starting structure:

group default      : 150 kpps /  800 Mbps per host
group dns          : 400 kpps /  1.5 Gbps per host
group game         :  80 kpps /  600 Mbps per host
prefix 192.0.2.0/24: 600 kpps /  4 Gbps aggregate

These numbers are placeholders to show the shape, not recommendations. Your baseline decides the values.

Build thresholds from a baseline

Do not guess. Collect two to four weeks of flow data and look at the top talkers by pps. With nfdump:

# top 20 destination IPs in the prefix by packet rate
nfdump -R /var/cache/nfdump/ -s dstip/pps -n 20 'dst net 192.0.2.0/24'

# top destinations by bps
nfdump -R /var/cache/nfdump/ -s dstip/bps -n 20 'dst net 192.0.2.0/24'

Remember that with sampled flows, the collector must scale counters by the sampling rate. If it does not, your baseline is too low by that factor.

Then:

1. Record the 95th and 99th percentile pps and bps per host group, not the maximum. Maximums include past attacks and backups.
2. Set the trigger at 2–4 times the 99th percentile for groups with stable traffic, and higher for bursty ones (CDN origins, backup servers).
3. Run in log-only mode for a week. Count how many alerts would have fired and review each one.
4. Lower or raise per group, not globally.

Exclude known attack periods from the baseline, or you will tune your detector to accept the attack.

Sampling and export timers affect thresholds

Your sampling rate sets the smallest attack you can see reliably. At 1:1000 sampling, a 20 kpps flood yields about 20 sampled packets per second across all flows, which is noisy. Very low thresholds on heavily sampled data produce false positives. Also check the active flow timeout: long timeouts add detection delay.

MikroTik (RouterOS v7):

/ip traffic-flow set enabled=yes interfaces=ether1 active-flow-timeout=30s inactive-flow-timeout=15s
/ip traffic-flow target add dst-address=198.51.100.10 port=2055 version=9

Cisco IOS-XE (Flexible NetFlow):

flow exporter NIXMON
 destination 198.51.100.10
 transport udp 2055
 export-protocol netflow-v9
flow monitor DDOS
 exporter NIXMON
 cache timeout active 15
 record netflow ipv4 original-input

On Linux with a software exporter, make sure the exporter's active timeout is also in the 10–30 second range. A collector that analyzes sub-second still depends on how quickly the router sends records.

Hysteresis: stop the flapping

Without hysteresis, traffic that hovers around the limit triggers, clears, triggers again. Each cycle can announce and withdraw a blackhole or FlowSpec rule, and each cycle sends a notification.

Use four controls:

• Trigger duration: The metric must exceed the limit for N consecutive seconds (for example 3–10) before an attack is declared. This filters single-sample spikes.
• Clear threshold: Declare the attack over only when traffic drops below a lower value, for example 50–70% of the trigger threshold.
• Minimum hold time: Keep the mitigation active for a fixed time (for example 5–15 minutes) after the last trigger before withdrawing it. Attackers often pulse.
• Re-trigger cooldown: If the same target re-triggers right after a clear, extend the hold time instead of opening a new incident.

Example profile:

trigger : > 150 kpps for 5 s
clear   : < 80 kpps for 60 s
hold    : 10 min minimum before withdraw
repeat  : extend hold by 2x on re-trigger within 30 min

Shorter hold times suit FlowSpec rules that drop only attack traffic. Be more careful with RTBH: it drops all traffic to the victim IP, so a premature withdraw restarts the outage and a long hold extends it.

Match the action to the confidence

Not every threshold crossing deserves the same response. Use tiers:

1. Low (about 1x–2x baseline peak): Log only. No page, no action.
2. Medium: Notify the team, attach top source ports, protocols and top sources.
3. High, with a clear signature: Announce a FlowSpec rule (for example UDP source port 123 to the victim).
4. Saturating link or no clean signature: RTBH for the victim IP, or divert through a scrubbing path if you have one.

Tiering is also the best defense against alert fatigue, because only the top tiers wake someone up.

Reducing alert fatigue

• Alert on incidents, not samples. One attack should create one incident with updates, not one message per second or per host.
• Page on action or impact only. Informational alerts go to a channel or a dashboard.
• Group by prefix. During carpet bombing, 200 per-host alerts hide the one that matters. Collapse them into a prefix-level incident.
• Whitelist known heavy flows. Backup windows, replication between your own sites and monitoring probes should have their own groups or exclusions.
• Review monthly. For every alert in the last month, ask: did it need a human? If not, change the threshold, group or tier.
• Track false positives and misses. A threshold you cannot measure cannot be tuned.

Common mistakes

• One global threshold for every customer.
• Only bps thresholds, which misses small-packet floods.
• No per-prefix limit, so carpet bombing is invisible.
• Setting limits at the maximum observed value, which includes old attacks.
• Forgetting to scale sampled counters.
• Clear threshold equal to the trigger threshold.
• Automatic RTBH on a low-confidence signal with no maximum duration.
• Never reviewing thresholds after adding a customer or upgrading a port.

A simple tuning workflow

1. Export flows from all edge routers and verify counters against interface graphs.
2. Group hosts by role, and define prefix aggregates.
3. Compute percentiles and set initial pps and bps limits.
4. Run log-only for 7 days, review alerts, adjust.
5. Enable notifications, then FlowSpec, then RTBH, one tier at a time.
6. Add hysteresis and hold times before enabling any automatic BGP action.
7. Re-check after every major customer or capacity change.

Where NixMon fits

NixMon ingests NetFlow v5/v9, IPFIX and sFlow with sub-second traffic analytics, and supports per-IP and per-prefix bps and pps thresholds. Mitigation actions include BGP blackhole (RTBH), BGP FlowSpec, the on-prem NixGuard firewall and NixGuard Edge. Attack alerts reach your team through the native iOS and Android apps. If you want to test your threshold profile against real traffic, you can start the 15-day free trial. No credit card is required.