Necessary cookies
Free network planning tool
Size for the traffic—and for a server failure.
Check the network budget of a filtering cluster. Add your own measured throughput to compare software limits, then see what remains when servers are unavailable.
Normal operation and server loss
All budgets below already reserve the selected headroom. Clean egress is sized for the conservative case where all incoming traffic must be forwarded.
Scroll horizontally to see every column.
| Scenario | Available servers | Network budget | Budget from your measurements | Assessment |
|---|---|---|---|---|
| All servers available | 2 | 160 Gbps | Not provided | Within the stated budgetSoftware capacity unknown |
| Unavailable servers : 1 | 1 | 80 Gbps | Not provided | Insufficient budgetSoftware capacity unknown |
Displayed values are rounded; the calculation retains full precision.
The path being sized
- Dirty ingress
- Filtering servers
- Clean egress
The model uses separate ingress and egress ports of equal speed. Shared trunks, one-arm designs, reverse-direction traffic and bypass links need their own budgets.
A small model, with visible assumptions
- Two peak scenarios
- The network requirement is the greater of the entered Gbps peak and the wire rate implied by the PPS scenario. These are separate planning cases, not a reconstructed traffic trace.
- Ports count once along the path
- With two 100G data ports, one is ingress and one is egress: the model starts with a 100G one-way budget, not 200G. Four ports provide two pairs, subject to working load distribution.
- Reserve capacity before counting servers
- Usable capacity = capacity × (1 − headroom / 100). Divide the required load by the usable per-server budget, round up, then add the selected server-loss allowance.
- Use both measured limits when available
- Measured Gbps cannot exceed the physical port budget in this model. The larger server count required by the Gbps and Mpps constraints is retained. No software measurement is inferred from a NIC speed.
What still needs a deployment test
- Validate NIC queues, PCIe capacity, NUMA placement, CPU and memory with the actual filtering rules and packet mix.
- Test distribution during normal operation and after failure. An aggregate budget does not prove that one flow, one prefix or a skewed hash fits.
- Check routing convergence, stateful sessions, MTU and clean return. Spare servers alone do not establish automatic failover.
- Keep upstream links within their own limits. Local software cannot recover traffic already lost on a saturated access circuit.
- Run throughput and failure qualification in an isolated, authorized test environment before relying on the plan.
Questions
Are two 100G ports counted as 200G of filtering capacity?
No. This model pairs one dirty-ingress port with one clean-egress port. That pair has a 100G one-way physical budget before headroom, and the software may sustain less.
Does the minimum server count certify Defense Fabric performance?
No. Without your measurements it is only a network-capacity floor. With measurements, it compares your supplied limits under stated assumptions; it is not a Peeryx benchmark or deployment acceptance test.
Why can the PPS input increase the Gbps requirement?
The planner converts the PPS scenario using the frame size you specify, including Ethernet wire-time overhead. It keeps the larger network requirement of that scenario and your separate Gbps peak. Check frame size and counter conventions if they differ substantially.
Will the calculator set up redundancy?
No. It calculates capacity with fewer available servers. Actual failover depends on routing, health detection, state handling, physical topology and a tested recovery procedure.
Technical references
Check the plan against your deployment
Use the Defense Fabric guide for integration requirements, or review a protected Transit design when the access network is the limiting factor.