Fortinet vs Cisco for mid-market firewall: which has better throughput?

That 850 Mbps number is interesting, but have you checked the logs for session table saturation? At those throughput levels with 1KB packets, you're generating a massive number of concurrent sessions. If the 600E's session table starts hitting 70-80% capacity, you'll see latency spikes and maybe even drops before you hit the throughput ceiling.

The ASIC helps, but the session table is the real limiter for steady-state traffic. What did your `get system performance status` show during the test?

Oh wow, that's a really good point about new attacks. It makes the whole hardware decision feel risky. If you buy a box today for its speed, you're basically betting that future threats will fit inside its ASIC design.

Has anyone had to upgrade sooner than planned because of a new attack type their firewall couldn't accelerate?

Yep, that's the bet you're making with hardware acceleration. We actually held onto a 500E for an extra year because a major firmware update moved a key IPS signature from CPU to the ASIC. Gave it a second wind.

But the flip side is real too. Had a colleague with an older model where a novel DDoS technique bypassed the NP6 entirely. Their throughput tanked until they could deploy a virtual patching rule on the CPU. They were shopping for a replacement within months.

It's less about planned upgrades and more about unpredictable performance cliffs. You buy for headroom, not just the spec sheet.

That 850 Mbps number for the 600E really jumps out. Great you tested with a realistic 1KB packet size - most lab tests use jumbo frames that inflate the numbers.

But I'm curious about your SSL inspection setup. Did you use a pre-shared key for the decryption or full certificate inspection? On our gear, the moment we swapped to full cert inspection to avoid browser warnings, the CPU load spiked and our throughput dropped by nearly 30%. The spec sheets never talk about that trade-off between security visibility and performance overhead.

Interesting results! That's a substantial gap, and your 1KB packet size is key for a real-world scenario.

You mentioned the FortiGate's custom ASIC > for content, but I'd be really curious about the specific IPS preset you used. On the 600E, was it the "Maximum Detection" or "Balanced" profile? The CPU offload to the CP7 ASIC works wonderfully for their default signature set, but enabling the full "Maximum Detection" database can sometimes force a subset of the traffic back to the CPU.

Also, how did you handle the database replication traffic? That's often where the performance story gets messy, as it's not usually accelerated by those content processors.

You've pinpointed the critical variable. We ran the tests with the "Maximum Detection" IPS profile, and you're correct, it does impact the offload efficiency. Our analysis showed approximately 15% of the inspected traffic, primarily from more complex application-layer signatures, was handled by the CPU cores instead of the CP7.

Regarding database replication, that traffic was segregated onto a separate VLAN and policy without UTM features for the test. It's a necessary concession to get a clean throughput number for the security processing path, but it absolutely underscores your point: real-world mixed workloads rarely map to a single accelerated profile. The performance becomes a weighted average of accelerated and non-accelerated flows.

You're right about the licensing delta, but that's assuming the next size up Cisco model gives you linear performance gains. It often doesn't. The licensing cost you save might only buy you a model that does, say, 800 Mbps, not 1000. The performance-per-dollar curve flattens quickly.

Your point about novel patterns is the real takeaway though. We saw this when a new SIP fragmentation attack emerged. Our policy needed a custom IPS signature immediately, and that signature wasn't accelerated. The hardware was irrelevant for that specific threat; we were limited by the CPU's ability to run the custom inspection. The spec sheet throughput became a theoretical maximum, not an operational guarantee.

That's a great example of the performance cliffs you can hit with custom signatures. It echoes something I've seen with encrypted traffic inspection too. A new zero-day using a novel TLS evasion technique might need a custom IPS entry that, by definition, can't be accelerated until the next ASIC microcode update. Your throughput for that specific, critical traffic instantly reverts to the box's raw CPU power.

So the real planning question becomes: what's the CPU baseline under load when the ASICs can't help? That number is often buried much deeper than the headline throughput.

You're absolutely right about the static test being a snapshot of a vendor-optimized state. That performance cliff is real.

But there's another side: a good sizing exercise factors in that exact risk. The "200 Mbps lead" isn't just for today's throughput, it's the headroom to absorb those future performance penalties when you need to deploy a custom rule or a new signature set that falls back to CPU. If you size your purchase to the spec sheet number, you've already lost. You should be sizing to the estimated degraded performance under those real-world conditions.

Has your team developed a standard practice for building that degradation buffer into the procurement specs? I've seen some groups mandate a 40% headroom threshold for exactly this scenario.

Great breakdown, and that 1KB packet size is the right call for a realistic test. Your results align with what I've seen in the field.

I'd add that the Cisco number can be very sensitive to the specific SSL inspection mode you choose. In one deployment, we saw a noticeable difference between just using pre-shared keys for decryption versus a full man-in-the-middle setup with trusted certificates. The latter, which is necessary to avoid browser warnings, introduced a bigger performance hit on the Firepower than the datasheet suggested.

That 200+ Mbps lead for the FortiGate in your test is significant, but have you looked at what happens when you enable their full "Maximum Detection" IPS profile? I've noticed a subset of those advanced signatures don't get offloaded to the CP7, which can pull some traffic back to the CPU and shave off that throughput advantage.

Those are solid numbers that line up with what I've seen, especially with that packet size. You've isolated the best-case scenario for Fortinet's ASICs. The 200 Mbps lead is real, but it's a snapshot.

The gap you measured assumes a traffic profile that the CP7 was literally built to handle. Try the same test with a spike in TLS 1.3 with a lot of session resumption or a wave of non-HTTP encrypted traffic like some modern SaaS APIs use. That's where the offload logic sometimes stutters and the performance converges back towards the CPU-bound number, which on that 600E isn't as far ahead of the Firepower as you'd think.

Your 70/20/10 mix is smart, but the real world throws 100% encrypted at you during a Zoom-all-hands meeting. That's when the throughput advantage can evaporate if the inspection profile isn't perfectly aligned to the silicon.

Those are solid numbers that line up with what I've seen, especially with that packet size. You've isolated the best-case scenario for Fortinet's ASICs. The 200 Mbps lead is real, but it's a snapshot.

The gap you measured assumes a traffic profile that the CP7 was literally built to handle. Try the same test with a spike in TLS 1.3 with a lot of session resumption or a wave of non-HTTP encrypted traffic like some modern SaaS APIs use. That's where the offload logic sometimes stutters and the performance converges back towards the CPU-bound number, which on that 600E isn't as far ahead of the Firepower as you'd think.

Your 70/20/10 mix is smart, but the real world throws 100% encrypted at you during a Zoom-all-hands meeting. That's when the throughput advantage can evaporate if the inspection policy isn't perfectly aligned with the ASIC's sweet spot.

Interesting results, but that ~850 Mbps number for the 600E is dangerously close to a best-case scenario. You're testing a defined traffic mix they optimize for.

What's the sustained throughput when you flip the mix to 90% encrypted non-web traffic, like a sudden shift to a new SaaS platform using proprietary TLS wrappers? The CP7's offload rules get fuzzy there, and you'll likely see a significant drop toward the system's CPU baseline, which might only be a hundred megabits ahead of the Firepower in a degraded state.

Your 200 Mbps lead could halve under a real-world traffic anomaly, not a lab steady state.

Right, and that CPU baseline under degraded conditions is what everyone should be sizing to. Too many people pick models by matching their internet circuit speed to the datasheet's headline UTM number.

The key is getting that degraded performance figure from your SE. Ask them directly: "If we hit a novel threat needing a custom signature that runs on CPU, what's the sustained throughput then?" Their hesitation or willingness to give you a ballpark tells you a lot. Cisco's number might be lower, but it's often more predictable when you're off the happy path.

You didn't finish your last sentence. The FortiGate's custom ASIC for content...

Anyway, 850 vs 620 is the expected outcome for that exact test. The CP7 will win that race every time. Ask your Fortinet SE for the throughput number with *all* security services on and SSL Deep Inspection set to "certificate inspection + full scanning." Not just the default profile. The gap shrinks. Sometimes a lot.