Packet capture is not about collecting more data. It is about collecting the right data, for the right duration, with predictable performance and cost. Organizations that treat packet capture as an afterthought often discover the problem too late: storage fills up, storage bills mount, investigations lack sufficient historical context, or compliance questions cannot be answered with confidence.
This article explains how to plan packet capture infrastructure at scale, focusing on realistic volume estimation, ingestion and compute requirements, and retention strategies using the IOTA platform.
Storage planning starts with understanding traffic behavior, not link speed. A 10 Gbps or 100 Gbps link rarely runs at line rate continuously, but burst behavior matters as much as sustained averages.
Key questions to answer:
Packet capture volume is best expressed as data per day, not bits per second.
If a link averages 2 Gbps sustained:
At this scale, small planning errors quickly become expensive.
At scale, capture systems fail more often due to ingestion bottlenecks than analysis limitations. Compute sizing must account for:
The IOTA 100 CORE is designed to keep capture reliability independent of the analysis workload, which is a critical capability. Dropping packets renders any subsequent investigation useless. By integrating high-throughput ingestion with customizable capture policies, IOTA ensures storage and compute resources can be precisely matched to your unique requirements.
Before choosing storage size, define:
Using IOTA capture management, you can define whether to capture full packets, filtered packets, metadata only, or a combination.
You can apply filters to optimize the use of available storage, like:
At a sustained 100 Gbps, the IOTA 100 CORE produces roughly 1,080 TB of data per day (decimal units). That works out to about 1.33 minutes of full packet capture per terabyte of storage. In practice, full packet capture retention (hours) ≈ storage (TB) × 0.0222. Using the same proportional assumptions as the original model, filtered packet capture retains ~20× longer than full packet capture, and metadata-only retains ~100× longer.
| Internal storage (TB) | Full packet capture | Filtered packet capture | Metadata only |
|---|---|---|---|
| 32 | 0h 43m | 14h 13m | 71h 07m |
| 64 | 1h 25m | 28h 26m | 142h 13m |
| 128 | 2h 50m | 56h 53m | 284h 26m |
| 307 | 6h 49m | 136h 26m | 682h 13m |
Most large deployments combine all three modes:
|
Use case |
Capture type |
Typical retention |
Storage impact |
|
Performance baselining |
Metadata only |
30 to 90 days |
Low |
|
Incident response |
Full packets on selected links |
7 to 30 days |
High |
|
Compliance investigations |
Full packets with controls |
Case dependent |
High |
A defensible retention policy is crucial to mitigate risk and requires robust governance. Key components include:
Profitap IOTA platforms are engineered to provide predictable, large-scale packet capture. By integrating IOTA with passive fiber TAPs and flexible capture management, users can achieve:
These are conservative, standard planning values:
Packet capture at scale is not about storing everything forever. It is about building visibility that remains useful, affordable, and trustworthy over time.