IPS Performance in R82/R82+: Why SND, CoreXL, SecureXL, PXL, PSL and Multi-Queue Matter More Than “I

[WiliRGasparetto]

IPS Performance in R82/R82+: Why SND, CoreXL, SecureXL, PXL, PSL and Multi-Queue Matter More Than “IPS is Enabled”

When troubleshooting IPS performance, the first question is usually:

“Which IPS protection caused the issue?”

That is a valid question.

But in high-throughput environments, it is not the best first question.

A better question is:

Where in the packet processing pipeline did the bottleneck appear?”

Because IPS enforcement is not just a signature engine behind an Access Control rule.

It is part of a broader gateway performance architecture that involves:

If we do not understand this chain, IPS troubleshooting becomes guesswork.

1. Why this topic matters

In real production environments, enabling IPS, changing a Threat Prevention profile or increasing inspection scope can expose bottlenecks that are not necessarily caused by a single IPS protection.

The symptom may look simple:

High CPU after enabling IPS

Throughput drops

Latency increases

Packet loss starts

One CPU core is much higher than others

Some flows are slow, while others are fine

HTTPS traffic behaves differently after inspection

But the root cause may be in different layers:

SND CPU saturation

FWK imbalance

Low acceleration ratio

Traffic moving from accelerated path to PXL/F2F

Elephant flows consuming specific workers

Multi-Queue not distributing traffic efficiently

PSL/PXL load increasing due to deep inspection

HTTPS Inspection increasing inspectable payload

One interface or VLAN concentrating most of the traffic

IPS profile too broad for the real exposure

This is why troubleshooting IPS performance requires a pipeline view.

Not only a blade view.

2. Important clarification: R82 did not “invent” Secure pipeline view.

Not only aXL, CoreXL, PSL, PXL or Multi-Queue

This is important to say clearly.

SecureXL, CoreXL, Multi-Queue, PSL and PXL are not new concepts that appeared only in R82.

They already existed in previous releases.

The real change in R82/R82+ is operational.

The gateway architecture, the traffic profile and the performance expectations make it much more important to understand how these components interact.

The correct message is not:

R82 has a completely new IPS architecture.

The correct message is:

R82/R82+ makes IPS troubleshooting much more dependent on understanding the full packet-processing and inspection pipeline.

Why?

Because modern environments have:

more encrypted traffic

more high-speed interfaces

more CPU cores

more east-west inspection

more cloud and hybrid flows

more advanced Threat Prevention profiles

more dependency on acceleration and partial acceleration

more elephant connections

more need to correlate SecureXL, CoreXL, PXL, PSL and Multi-Queue

3. The IPS pipeline: what actually happens

A simplified packet-processing view looks like this:

This is the key point.

When IPS impacts performance, do not look only at the IPS profile.

Look at the path the packet took.

4. Example architecture: SND and FWK roles

In an 8-core example, the CPU split may look like this:

CPU 0-1  → SND cores

CPU 2-7  → CoreXL FWK instances

This is only an example. The actual split depends on appliance, version, CoreXL configuration, interface load, blades and tuning.

But the concept matters.

SND and FWK cores do different jobs.

If SND cores are high, investigate:

Interface RX/TX processing

Multi-Queue status

Interrupt distribution

SecureXL decision path

Traffic concentration on specific interfaces

High packet rate

Queue distribution

 If FWK cores are high, investigate:

IPS / Threat Prevention profile

HTTPS Inspection

Application Control

VPN

Non-accelerated or partially accelerated traffic

PXL / PSL workload

Heavy connections

Elephant flows

High CPU is not enough.

You need to know:

Which CPU role is high?

That one distinction can change the entire troubleshooting path.

5. R81.x and lower vs R82/R82+: what changes in troubleshooting?

A direct comparison helps avoid wrong conclusions.

The key point:

Older versions: many investigations focused on IPS profile and protections.

R82/R82+: investigations must also focus on where the flow moved in the performance pipeline.

6.  SecureXL and PXL: IPS does not always mean “full slow path”

A common misunderstanding is:

“If IPS is enabled, SecureXL is no longer relevant.”

That is not accurate.

SecureXL remains very relevant because traffic may be handled through different paths:

Fully accelerated path

Partially accelerated path

PXL path

F2F / full inspection path

For IPS-related traffic, PXL is especially important.

PXL combines SecureXL and PSL.

It allows the gateway to benefit from acceleration while still using stream processing for deeper inspection.

Useful commands:

bash

fwaccel stats -s

fwaccel stats

fwaccel stats -x

fwaccel conns

cpview

Important areas to observe:

Accelerated packets

F2F packets

PXL packets

PXL bytes

PXL connections

Connection templates

Acceleration ratio

If traffic suddenly moves from accelerated or PXL paths into a more expensive inspection path, the performance impact can be significant.

7. PSL: why IPS needs stream awareness

IPS cannot reliably inspect only isolated packets.

Many attacks only become visible when the TCP stream is reconstructed.

That is where  PSL — Passive Streaming Library — becomes important.

PSL helps the gateway handle:

TCP stream reassembly

out-of-order packets

retransmissions

payload overlaps

stream normalization

some evasion attempts

TCP-layer security conditions

This matters because attackers may try to hide malicious payloads across multiple packets, retransmissions or overlapping segments.

So when troubleshooting IPS, remember:

PSL is not “extra overhead for no reason.”

It is part of making IPS inspection reliable.

The tradeoff is that deeper stream-aware inspection consumes resources.

8. Multi-Queue: interface-level scalability can decide the case

Multi-Queue allows supported interfaces to use multiple RX/TX queues.

This matters because a high-speed interface sending most traffic through a small number of queues can create CPU imbalance before IPS is even the real bottleneck.

Useful commands:

bash

mq_mng --show

mq_mng --show -v

show interface <interface> multi-queue

show interface <interface> multi-queue verbose

Important questions:

Is Multi-Queue supported on the interface?

Is it enabled?

How many queues are active?

Which CPU cores process these queues?

Is traffic concentrated on one queue?

Are SND cores overloaded?

Is the interface receiving most of the traffic?

A Multi-Queue issue can easily be misdiagnosed as:

IPS is slow.

When the real issue is:

Traffic is not being distributed efficiently before it even reaches deeper inspection.

9. HyperFlow and elephant connections

Heavy connections and elephant flows can create very specific performance symptoms.

Examples:

One FWK much higher than others

One large flow consuming a disproportionate amount of CPU

New small flows look fine, but large flows suffer

Throughput does not scale as expected

This is where heavy-connection visibility becomes important.

Useful commands:

bash

fw ctl multik stat

fw ctl multik print_heavy_conn

cpview

top

The question is:

Is the performance issue caused by many flows, or by a few heavy flows?**

Those are different problems.

They require different troubleshooting strategies.

10. Why HTTPS Inspection changes the IPS performance discussion

HTTPS Inspection changes how much traffic becomes visible for deeper inspection.

Without HTTPS Inspection, IPS may have limited visibility into encrypted payload.

With HTTPS Inspection, more payload becomes inspectable.

That is good for security.

But it also changes the performance profile.

So if latency or CPU increases after enabling IPS and HTTPS Inspection together, do not analyze them as unrelated topics.

Ask:

Did HTTPS Inspection increase the amount of payload available to IPS?

Did traffic move to PXL/F2F?

Did PSL workload increase?

Are FWK cores now higher?

Did the Threat Prevention profile become too broad for this traffic segment?

Are the relevant protections aligned with the exposed services?

In many cases, the symptom is described as:

IPS caused latency.

But a more accurate analysis may be:

HTTPS Inspection exposed more application payload to Threat Prevention, moving more traffic into expensive inspection paths.

11. Practical troubleshooting map

12. Minimum evidence package

When opening a TAC case or asking the community, I would include:

Gateway version and Jumbo Take

Appliance model / Open Server specs

Number of CPU cores

CoreXL configuration

SND / FWK distribution

SecureXL status

Multi-Queue status

Threat Prevention profile

IPS protections involved

Traffic type: cleartext, HTTPS, VPN, east-west, north-south

Whether HTTPS Inspection is enabled

Before/after CPU screenshots from CPView

fwaccel stats output

PXL/F2F counters

fw ctl multik stat output

mq_mng --show -v output

heavy connections output

Exact timestamp of the issue

Relevant IPS logs

Useful commands:

Bash

cpview

fwaccel stats -s

fwaccel stats

fwaccel stats -x

fwaccel conns

fw ctl multik stat

fw ctl multik print_heavy_conn

mq_mng --show -v

top

For advanced debugging, I would not start with broad kernel debug in production unless the scope is clear.

Start with counters, CPView, logs and flow-level evidence.

13. Design considerations for IPS performance

A good IPS design is not only about enabling protections.

It is about matching inspection depth to risk.

Consider segmenting IPS policy by exposure:

Internet-facing servers

DMZ

User networks

Data center east-west traffic

Branch traffic

OT/ICS segments

Cloud workloads

VPN traffic

Management networks

Not every segment needs the same IPS profile.

A production-grade IPS rollout should consider:

Which assets are exposed?

Which services are reachable?

Which protections are relevant?

Which exceptions are justified?

Which traffic is encrypted?

Which flows require HTTPS Inspection?

Which segments generate the most throughput?

Which gateways are CPU-bound?

Which business applications are latency-sensitive?

That is how you reduce risk without turning IPS into a performance bottleneck.

14. The wrong way to tune IPS

I would avoid these anti-patterns:

Disabling IPS globally to solve performance

Creating broad IPS exceptions without owner

Using one IPS profile for all network segments

Ignoring SND vs FWK CPU distribution

Ignoring SecureXL / PXL / F2F counters

Ignoring Multi-Queue on high-speed interfaces

Treating HTTPS Inspection and IPS as separate performance topics

Looking only at drops instead of packet path

Tuning protections before understanding the bottleneck

These actions may temporarily reduce symptoms, but they do not create a mature security posture.

15. The right way to think about IPS in R82/R82+

A better model is:

This model helps answer the real questions:

Where is the packet spending CPU?

Is the traffic accelerated, partially accelerated or fully inspected?

Is the bottleneck on interface queues, SND, FWK, PSL/PXL or IPS protections?

Is the IPS profile aligned with the segment risk?

Is HTTPS Inspection changing the inspection workload?

Is the hardware being used efficiently?

16. How I would explain the R82/R82+ value to customers

I would not say:

R82 has a completely new IPS architecture.

I would say:

R82/R82+ gives more value to customers who understand and operate the full performance pipeline.

The business message is:

Better performance is not only about upgrading.

It is about using the architecture correctly.

The technical message is:

R82/R82+ makes it even more important to correlate CoreXL, SecureXL, PXL, PSL, Multi-Queue, HyperFlow, Threat Prevention profile and real traffic patterns.

That is what separates a basic IPS deployment from a production-grade IPS architecture.

17. Final thought

IPS performance troubleshooting is not only about signatures.

It is about understanding the full gateway architecture.

If you only ask:

“Which IPS protection caused the issue?”

you may miss the real bottleneck.

A better question is:

“How did this flow move through SecureXL, CoreXL, Multi-Queue, PXL, PSL and the IPS engine?”

That is the difference between disabling security to restore performance and engineering a gateway that can deliver both security and throughput.

Discussion

How do you troubleshoot IPS performance today?

Do you start with CPView and CoreXL/SecureXL counters before changing IPS profiles?

Have you seen SND saturation being mistaken for “IPS is slow”?

How are you using Multi-Queue, PXL counters and heavy-connection visibility in R82/R82+ environments?

Do you treat HTTPS Inspection and IPS as one combined performance topic or as separatetroubleshooting areas?

[PhoneBoy]

With SND cores being 100%, it's important to know whether you are in UPPAK or KPPAK.
The reason being is that top/ps will show 100% if in UPPAK, but it's not real usage due to poll mode drivers.

[Lesley]

Great post / guide, shared it on my Linkedin aswell.

Phoneboy refers to https://support.checkpoint.com/results/sk/sk180299 btw, but I assume you already aware of this. 

[WiliRGasparetto]

Yes, I'm already aware. Go ahead and share your LinkedIn so we can like the post there, hehe.

[WiliRGasparetto]

Exactly that and a point worth noting.