> Source: [sk180633](https://support.checkpoint.com/results/sk/sk180633)

# sk180633 - Security Gateway accelerates 99% of traffic through the PSLXL

| Property | Value |
|----------|-------|
| Solution ID | sk180633 |
| Date Created | 2023-02-19 |
| Last Modified | 2023-05-09 |
| Technical Level | Advanced |
| OS | Gaia |

## Symptoms

- * The Security Gateway experiences high CPU on its CoreXL instances. The example below is from a 6900 Appliance with 16 Cores (2 SND and 14 CoreXL):

  ```
  
  top - 14:58:30 up 49 days, 13:54,  1 user,  load average: 10.59, 10.61, 10.68
  Threads: 691 total,  20 running, 671 sleeping,   0 stopped,   0 zombie
  %Cpu(s): 44.0 us, 10.5 sy,  0.0 ni, 41.5 id,  0.0 wa,  0.6 hi,  3.4 si,  0.0 st
  KiB Mem : 32663536 total,  8703372 free, 12060304 used, 11899860 buff/cache
  KiB Swap: 32964476 total, 32964476 free,        0 used. 18664288 avail Mem 
  ```

* The output of the "`fwaccel stats -s`" command shows 99% through the PSLXL path:

  ```
  
  [Expert@hostname:0]# fwaccel stats -s
  Accelerated conns/Total conns : 0/59292 (0%)
  LightSpeed conns/Total conns : 0/59292 (0%)
  Accelerated pkts/Total pkts : 607841816649/608927945802 (99%)
  LightSpeed pkts/Total pkts : 0/608927945802 (0%)
  F2Fed pkts/Total pkts : 1086129153/608927945802 (0%)
  F2V pkts/Total pkts : 5480422468/608927945802 (0%)
  CPASXL pkts/Total pkts : 0/608927945802 (0%)
  PSLXL pkts/Total pkts : 607840098111/608927945802 (99%)
  ```

* The Access Policy rulebase, merged with Application Control and URL Filtering blades' policies and Inline Layers, are incorrectly ordered, causing early triggers of the inspection engines.

## Cause

This behavior is expected:

* Incorrect order of inspection rules, where high amount of traffic is matched, causes higher CPU utilization and decreases performance while the concurrent connection rate may be low.
* When you enable the Application Control and URL Filtering Software Blades, acceleration is partial for the matched traffic and traffic goes through the Medium Path (PSLXL).
* When the firewall matches connections on URL Filtering / Application Control rules (based on \[1\]Destination IP, \[2\]Source IP, and \[3\]Service Type/port), it tags them as a "Possible Match".  

  As further inspection is needed from the URL Filtering / Application Control engines to determine a final match on the appropriate signatures/ports configured for each rule.  

  Since the FW only received the TCP handshake packets at that point, it waits for the data packets to arrive too. The data packets trigger the relevant engine (URLF/APPI) for deeper (payload) inspection.  

  When enough information is gathered, the FW changes the tags accordingly ("Final Match", "No Match", or, if there isn't enough information to conclude, "CPNotEnoughDataForRuleMatch" \[sk113479\]).  

  **This behavior consumes resources**. Hence, if the rulebase isn't configured correctly, the engines are triggered more than needed for simpler rules (lower in the OSI model) that could have been matched earlier if placed higher in the rulebase.

## Solution

This solution requires authentication. Please log in to view the full solution.

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content