A real-life situation
Northwick Clinics, a fictional healthcare group, buys a FortiGate because its data sheet shows a firewall throughput ten times the clinic's Internet link. After go-live, with IPS, web filtering and SSL deep inspection enabled, browsing slows down at lunchtime and the CPU sits near 100 per cent. The firewall is working as specified. The figure the buyer looked at assumed no inspection at all; the figure that mattered was the inspected one, and it was smaller than the clinic's peak. This lesson shows how to read the data sheet and size from the right numbers.
Why sizing needs care
A FortiGate does very different amounts of work per packet depending on what you ask of it. Forwarding an offloaded session costs almost nothing; decrypting, inspecting and re-encrypting it costs a lot. A data sheet therefore gives several throughput figures, each under its own test conditions. Choosing by the wrong one is the most common sizing mistake, and it is expensive to fix after installation.
Learn more: Security Processors and Hardware Acceleration
The data sheet figures, one by one
| Figure | What it measures | What it tells you |
|---|---|---|
| Firewall throughput (1518 / 512 / 64-byte UDP) | Forwarding with a simple policy and no inspection, at three packet sizes | The ceiling for plain, offloaded forwarding. Small packets give lower numbers because per-packet work dominates. |
| Firewall latency (64-byte UDP) | Delay added to a small packet | Matters for trading, voice and storage traffic; usually microseconds for offloaded traffic. |
| Firewall throughput (packets per second) | Small-packet forwarding rate | Useful for voice, DNS-heavy or DDoS-exposed networks. |
| Concurrent sessions | Size of the session table | Limits how many connections can be open at once. |
| New sessions per second | Session setup rate | Limits bursts: many users logging in, web pages with many connections, scans. |
| Firewall policies | Maximum number of policies | Rarely the limit, except in large multi-tenant designs. |
| IPsec VPN throughput | Encrypted site-to-site forwarding, at a stated packet size | For site-to-site designs; real traffic and other algorithms are often lower. |
| IPS throughput | Traffic with IPS enabled, usually an enterprise mix | The first inspected figure. |
| NGFW throughput | Typically firewall, IPS and application control | For designs with application-aware policies. |
| Threat protection throughput | Typically NGFW plus malware protection | The usual figure for a full UTM design. |
| SSL inspection throughput | Decrypted, inspected HTTPS, with a stated profile | Critical when most traffic is encrypted and you deep-inspect it. |
| Application control throughput | Application control alone, often with large HTTP objects | Usually optimistic compared with real traffic. |
| Max FortiAPs / FortiSwitches / users | Management limits | Hard limits for Security Fabric designs, independent of traffic. |
Exactly which features each inspected figure includes, whether logging was on, and what traffic mix was used are stated in the data sheet's footnotes. Read them. They change between data sheets over time, and they decide whether two figures are comparable.
Why the numbers are so different
- Packet size. 1518-byte packets carry the most data per packet, so the per-packet cost is spread over more bytes. Real traffic averages smaller.
- No inspection. The firewall figure uses a single permissive policy. Nothing is decrypted or scanned.
- Offload. On models with a network processor, the firewall figure is mostly NP forwarding. Inspected figures need the CPU (with content processor help), which is a much smaller resource.
- Traffic mix. Inspected figures use realistic mixes of HTTP, HTTPS, email and other protocols with varied object sizes. Larger HTTP objects give better numbers, so check what size was used.
Vendors test in their own labs with tuned configurations. Independent tests and your own pilot are useful checks. Treat every figure as a best case under the footnoted conditions, not a guarantee.
A sizing method
1. Measure
Measure at the busiest time of the busiest days, not as a daily average. Useful sources are the current firewall's monitoring, the Internet router's interface counters, NetFlow or a monitoring system. You need four numbers: peak throughput, peak concurrent sessions, peak new sessions per second, and the share of traffic that is encrypted (on most networks today, the large majority).
2. Decide the features
Write down what each policy will do. A data centre segment with firewall-only policies is sized by firewall figures; user Internet access with IPS, application control, antivirus and web filtering is sized by threat protection; if that traffic is also deep-inspected, the SSL inspection figure becomes the constraint.
3 and 4. Growth and headroom
Multiply the measured peak by the expected growth, then add headroom on top. Headroom covers bursts, features enabled later, firmware differences and the gap between lab and real traffic. Running a firewall continuously near its limit leaves no room for an attack or an incident.
5 and 6. Compare and check the extras
- HA. In an active-passive cluster one unit carries everything after a failover, so each unit must handle the full load. Active-active spreads some inspection, but size so one unit can still survive alone.
- Logging. Logging every session, especially to local disk, adds CPU and disk load. Sending logs to FortiAnalyzer or a cloud service moves storage off the FortiGate but still costs some processing.
- VPN users. Remote access users add tunnels, encryption and sessions; check the tunnel limits and the IPsec figure.
- Fabric devices. FortiAP, FortiSwitch and FortiToken limits are fixed per model.
- Interfaces. Enough ports of the right speed and type (copper, SFP, SFP+), and NP-connected where traffic is heavy.
Worked example with a hypothetical data sheet
The models and figures below are fictional, invented to show typical ratios. They are not Fortinet figures for any real model.
| Figure (hypothetical) | Model A | Model B | Model C |
|---|---|---|---|
| Firewall throughput (1518 / 512 / 64 byte) | 10 / 10 / 7 Gbps | 27 / 27 / 18 Gbps | 80 / 80 / 60 Gbps |
| Concurrent sessions | 700,000 | 3,000,000 | 8,000,000 |
| New sessions per second | 35,000 | 250,000 | 500,000 |
| IPsec VPN throughput | 6.5 Gbps | 20 Gbps | 55 Gbps |
| IPS throughput | 1.4 Gbps | 3.5 Gbps | 12 Gbps |
| NGFW throughput | 1.0 Gbps | 3.0 Gbps | 10 Gbps |
| Threat protection throughput | 0.7 Gbps | 2.5 Gbps | 9 Gbps |
| SSL inspection throughput | 0.6 Gbps | 2.8 Gbps | 8 Gbps |
Northwick Clinics measures and decides:
- Peak Internet traffic 650 Mbps, 85 per cent of it encrypted.
- Peak 120,000 concurrent sessions and 2,500 new sessions per second.
- Features: threat protection on all user traffic, deep SSL inspection on most of it.
- Growth: 40 per cent over the firewall's planned life. Headroom: 40 per cent.
- Design: an active-passive HA pair.
| Requirement | Calculation | Target |
|---|---|---|
| Inspected throughput | 650 Mbps × 1.4 growth × 1.4 headroom | about 1.3 Gbps |
| SSL-inspected throughput | 1.3 Gbps × 0.85 encrypted | about 1.1 Gbps |
| Concurrent sessions | 120,000 × 1.4 × 1.4 | about 235,000 |
| New sessions per second | 2,500 × 1.4 × 1.4 | about 4,900 |
Model A's firewall figure (10 Gbps) looks ample, but its threat protection (0.7 Gbps) and SSL inspection (0.6 Gbps) figures are below the targets: this is the trap Northwick fell into. Model B meets every target with margin. Its sessions and setup rate are far above need, which is normal: for user Internet access, inspected throughput is usually the constraint. Because the design is active-passive, each unit must meet the targets on its own, so the purchase is two Model B units.
One more check: the SSL inspection figure may be measured with only IPS enabled (read the footnote). With full threat protection on decrypted traffic, real capacity will be lower than either figure alone. Model B's margin over 1.3 Gbps covers that here; with a tighter result, a pilot or the next model up is the safer choice.
Signs that a FortiGate is undersized
- High CPU at peak. Sustained high CPU while traffic is high, with slow browsing or VPN complaints.
- High memory and conserve mode. Memory use climbs until the FortiGate enters conserve mode.
- Session table near its limit. New connections fail while existing ones keep working.
- Setup rate limit. Bursts of new connections (for example at the start of the working day) are slow or dropped.
Conserve mode protects the FortiGate when memory runs low. It is controlled by three memory thresholds: entering at the red threshold, a stricter state at the extreme threshold, and leaving when use falls below the green threshold. In FortiOS 7.6 the defaults are 88, 95 and 82 per cent of memory, and each can be set between 70 and 97. In conserve mode the FortiGate restricts new work, and depending on settings may pass or block traffic that it can't inspect, which is either a security gap or an outage. A later production module covers conserve mode in depth; for sizing, the point is that a correctly sized FortiGate doesn't visit it during normal operation.
Monitoring capacity
In the GUI, the dashboard widgets for CPU, memory and sessions show current use and recent history; check them at your busiest hours. In the CLI:
get system performance statusOne-screen summary: CPU states, memory use, average network usage, session count and session setup rate.
FGT1 # get system performance status CPU states: 2% user 6% system 0% nice 87% idle 0% iowait 0% irq 5% softirq CPU0 states: ... Memory: 3999716k total, 1621084k used (40.5%), ... Average network usage: 412340 / 398120 kbps in 1 minute, ... Average sessions: 118402 sessions in 1 minute, ... Average session setup rate: 2390 sessions per second in last 1 minute, ... ... Uptime: 41 days, 6 hours, 12 minutes
softirq often means the CPU is handling packet forwarding itself, for example traffic that isn't offloaded.diagnose sys topLive list of processes by CPU and memory use. Press q to quit. Look for which daemon (for example the IPS engine or a proxy) is using the CPU.
diagnose hardware sysinfo conserveShows the memory conserve mode state and thresholds on recent releases.
The sizing method is the same on both releases. Memory use, default thresholds and the output format of these commands can change between releases and builds, and new firmware can use more memory than old firmware on the same model. Check the release notes before upgrading a FortiGate that is already close to its limits.
What can go wrong
Fine at go-live, slow a few months later
Performance was good on day one; now users complain at peak times and CPU is high.
Show the cause and fix
Features were added after the original sizing (often SSL deep inspection or more security profiles), or traffic grew faster than expected. Compare current peak traffic and features with the figure the model was chosen by. Short term, review which policies really need deep inspection or proxy features; long term, plan a larger model sized with the method above.
New connections fail at 9 a.m.
Existing sessions work, but some users can't start new ones during the morning rush.
Show the cause and fix
Check the session count and setup rate in get system performance status during the rush. If they are near the model's limits, the session table or setup rate is the constraint. Look for causes that inflate sessions (a scanning host, long idle timeouts, a misbehaving application) before buying; if the load is legitimate, size the replacement by sessions and setup rate.
The cluster struggles after a failover
Performance is fine until one HA member fails, then the survivor is overloaded.
Show the cause and fix
The cluster was sized for the combined capacity of two units. Each unit must handle the full peak alone. Reduce inspection load or replace with models that can carry the full load individually.
Design guidance for enterprises
- Size each role separately: Internet edge (inspected throughput), data centre segmentation (firewall throughput, sessions, latency), site-to-site hub (IPsec throughput and tunnel counts).
- Pilot the shortlisted model with your own traffic and features when the margin is small.
- Plan for the firewall's whole life: link upgrades, new sites, more encrypted traffic and new features.
- Record the measured figures and assumptions with the design, so the next sizing starts from facts.
Best practices
- Choose by the inspected figure that matches your feature set, and read its footnotes.
- Measure peaks, not averages, and include sessions and setup rate.
- Add growth and headroom; size each HA member to carry everything.
- Monitor CPU, memory and sessions after go-live and after every new feature.
🛠 Practical exercise: size a firewall from your own numbers
On a network you know (or a lab FortiGate with test traffic), record the peak session count and setup rate from get system performance status and the peak throughput from the dashboard or interface counters. Estimate the encrypted share. Choose the features you would enable, apply 40 per cent growth and 40 per cent headroom, and pick a model from the hypothetical table in this lesson. Then open a real FortiGate data sheet, find the figure that matches your features, and read its footnotes: write down the traffic mix and the features it was measured with.
Key takeaways
- The firewall figure assumes large packets, no inspection and hardware offload; inspected figures are much lower.
- Size by the inspected figure matching your features, plus sessions and setup rate, and read the footnotes.
- Measure peaks, then add growth and headroom; 30 to 50 per cent headroom is common practice.
- Each active-passive HA member must carry the full load alone.
- High CPU, conserve mode and a full session table are signs of an undersized FortiGate.
Check yourself
A company will run IPS, application control and antivirus on all Internet traffic. Which data sheet figure should it compare with its peak traffic?
Why is the 64-byte firewall throughput lower than the 1518-byte figure?
An active-passive pair must handle 2 Gbps of threat-protected traffic. Each candidate model is rated at 1.2 Gbps threat protection. Is the pair big enough?
get system performance status shows 85 per cent idle CPU, but memory is at 90 per cent and climbing. What risk is closest?
Next: see how the first packet and every later packet are processed in Understanding FortiGate firewall packet flow, and how HA pairs share the load in High availability.