Hardware sizing & capacity planning
Size an appliance to your network in seconds — then read how the numbers were measured: the throughput ceiling, the serve-vs-deny trade-off under attack, and storage by retention.
Capacity planner
Size your deployment
Describe your network below — every number updates live as you drag a control. It accounts for everyday renewals, the constant floor of misbehaving devices, and a transient recovery storm. It's a planning estimate extrapolated from measured performance, not a quote.
| Retention | Provisioned | Raw |
|---|
How we calculate this
Everything here extrapolates from a single set of constants measured on a real appliance under load tests — no hidden fudge factors. The math runs entirely in your browser.
Steady state
Each device holds 1 lease (single-stack) or 2 (dual-stack). A device renews at half its lease time, so steady renewals per second are leases ÷ (leaseHours·3600 ÷ 2). Each renewal is 2 packets and 2 stored events.
Faulty-device floor
Real networks carry a constant share of misbehaving devices — broken firmware, retry loops. With F% of devices each sending m messages/min, that's devices · F/100 · m ÷ 60 inbound packets/s, parsed continuously. This floor is always on — it doesn't recover like a storm. Denied, it costs only parse CPU; blocked, every message is also stored, so it drives memory and disk too.
Storm peak
A storm brings a share of devices back at once. Those acquisitions spread across your recovery window: acquisitions/s = storm leases ÷ (recovery minutes · 60). Each acquisition is 4 packets and 4 stored events. A legitimate storm is served and stored; an attack is denied at the edge and not stored. Peak = steady + floor + storm.
Appliance
Parsing scales at 15,000 packets/s per core. The store adds 0.065 core and 0.45 GB RAM per 1k / 10k stored-events per second, on a small base. We then provision to standard tiers with 1.5× headroom on cores and 1.25× on memory.
Storage
Each stored event is 27 bytes on disk — already compressed roughly 34×. Storage is driven by the steady stream over the retention window, then provisioned with 1.5× headroom.
Taken off the DHCP server
The chatty floor is denied at the edge — under either policy — so it never reaches the DHCP server: floorPps requests/s, or floorPps · 86,400 a day. At the same 27 bytes/event that's a comparable raw volume the server doesn't log or retain. It's a conservative figure — uncompressed server logs are typically larger.
Measured constants
These figures are planning estimates extrapolated from measured performance. For very large deployments we're glad to validate the numbers with you against a scaled load test.
Sizing is independent of your licence tier. The figures here are capacity guidance for a single appliance, not the pricing plans. One appliance is sized by the traffic it carries, not by which tier — Starter, Pro, or Enterprise — you licence it under. See /pricing for the tiers and their lease limits, and “Scaling out” below for estates beyond one appliance.
Method
How to size
DHCP is a low-bandwidth, bursty protocol: the CPU spent parsing and classifying packets is almost always the bottleneck before the NIC is. Size to your peak request rate, not your average. The work parallelizes naturally across CPU cores, so adding cores is the primary lever for higher rates.
Two kinds of load sit above the everyday renewal traffic, and they behave differently:
- A constant floor of misbehaving devices — broken firmware and retry loops that chatter continuously. This never recovers; it's an always-on parse cost the appliance absorbs at the edge. At scale a small share of bad devices can dominate inbound traffic outright, so size cores for it as steady load, not as a spike.
- Transient recovery storms — mass renewal at lease expiry, or reacquisition after an outage. These are real spikes, but DHCP's exponential backoff spreads them out: clients retry and stagger, so a storm drains over minutes. Size these to an acceptable recovery window, not to the instantaneous peak.
The figures here come from a reference appliance — 16 vCPU, 60 GB RAM — driving 250,000 dual-stack devices under load, then extrapolated linearly. That's the same model the calculator above runs; its exact constants are listed under its “How we calculate this” panel.
The figures here come from a reference appliance — 16 vCPU, 60 GB RAM — driving 250,000 dual-stack devices under load, then extrapolated linearly. That's the same model the calculator above runs; its exact constants are listed under its “How we calculate this” panel.
Benchmark
What we measured
A few anchor points from the load tests, before the calculator extrapolates from them:
- Parsing throughput — about 15,000 packets/s per core. Inbound traffic peaked near 80,000–85,000 packets/s at roughly 5 cores, with unwanted traffic dropped in the kernel before it reaches the database.
- A clean 250k-device estate is light — around 420 inbound packets/s, 780 stored events/s, under 0.6 of a core, and about 1.5 GB/day of disk.
- Compute scales with packet rate, not device count — a renewal storm or outage recovery drives the peak; steady-state traffic is a small fraction of it.
Mapped to host footprints for a 250k-device deployment, by mitigation policy under attack:
| Profile | vCPU | RAM | Disk (SSD) | Write IOPS | NIC |
|---|---|---|---|---|---|
| Baseline · steady-state | 2 | 4 GB | 50 GB | < 700 | 1 GbE |
| Under attack · deny | 8 | 8 GB | 100 GB | ~3,500 | 1 GbE |
| Under attack · serve + store | 8 | 16 GB | 250 GB | ~3,500 | 1 GbE |
- Architecture:
amd64, on a modern Debian-based Linux (recent Ubuntu LTS or Debian) with a current kernel — nftables and NFQUEUE are standard, no out-of-tree modules. - Deployment unit: a dedicated VM or container is the recommended footprint, placed inline so it sees DHCP traffic directly.
- NIC: prefer a multi-queue NIC (RSS/RPS) so packet processing spreads across cores. 1 GbE is fine for most sites — even the ~85k packets/s ceiling sits well under 200 Mbps; 10 GbE is about packet-rate headroom under bursty traffic, not raw bandwidth.
Under load
Serve vs deny
When traffic turns hostile, what you do with the offending packets is the single biggest driver of appliance size. The calculator's storm type toggle models the two policies, and the gap between them is large.
Against a sustained attack on the same 250k-device estate — roughly 85,000 packets/s inbound, the overwhelming majority unwanted:
- Deny drops offenders at the edge and doesn't store them: about 956 stored events/s, ~0.7 GB of working memory, and ~0.08 GB/h of disk.
- Serve and store the offending events instead: about 22,800 stored events/s, ~11 GB of working memory, and ~1.8 GB/h of disk.
Denying at the edge writes roughly 24× fewer events and uses about 15× less memory for the same drop reliability. The binding constraint when you serve and store an attack is memory — the buffer that absorbs the write rate — not the database, which had headroom to spare in every test. That's why moving the calculator's toggle to attack · deny drops the recommended RAM and storage so sharply.
The same choice governs the constant floor of misbehaving devices, where it matters even more — because the floor is continuous, not a one-off event. Deny it and the appliance pays only the parse cost, around the clock, while storage and memory stay flat. Block it and you store that junk every second of every day: in the calculator, flipping the floor's filter policy to Block turns a tidy footprint into one whose disk and memory climb without bound. Detecting and dropping the floor at the edge — without storing it — is the appliance's core job.
That filtering is also what the appliance hands back. Every chatty request it denies is one the DHCP server never has to answer, and — at the same measured event size — a comparable volume it never has to log or retain. At scale that runs to billions of requests a day and tens of gigabytes of daily churn kept off the server; the calculator's “Taken off the DHCP server” band works it out from your own numbers.
Size for your policy. Deny bad traffic at the edge — the efficient choice — and the appliance stays small. Choose instead to retain it for forensics and memory and disk become the cost; the calculator shows both ends, for storms and for the constant floor.
Storage
Storage planning
DHCP events are stored in a local ClickHouse instance with compression; the events table dominates storage cost. Each stored event lands at roughly 27 bytes on disk — already compressed about 34× from the raw event.
Storage is driven by your steady-state traffic and is independent of storm size — storms are transient, the renewal stream is not. Size disk by retention window: the calculator's storage panel shows 30-day, 90-day, 12-month, and 24-month figures with 1.5× headroom. Heavy Option 82 sub-options or long vendor-class strings push the per-event size up, so measure against a short pilot before committing disk.
Event retention is configurable per installation; longer windows or higher rates need proportionally more disk.
Scale
Scaling out
What about traffic spikes?
Size with at least 2× headroom over your steady-state peak. DHCP bursts (outage recovery, mass lease renewal) last seconds, not minutes, and are absorbed in the kernel queue depth. Sustained overload, rather than spikes, is the signal to add cores or shard.
Can I run more than one appliance?
Yes. Multiple appliances run independently, each writing to its own local store; you build aggregate views downstream. For distributed estates, remote sites can be covered by mirrored or TZSP capture forwarded to a central collector — see covering isolated and remote sites.
Keep reading
Related
Run a pilot. Real performance depends on traffic mix, inspection depth, and storage IOPS. The numbers above and in the calculator are planning estimates extrapolated from measured performance; run a short pilot in your environment to confirm the footprint before you commit.
Plan your deployment.
Size it above, then tell us your topology — we'll confirm the fit against your traffic.