Show me yours

[ED]

Hi everyone,

After watching the excellent webinar of Tim Hall's 'Security Gateway Performance Optimization' I'm sure you have tried all seven commands on your security gateway. The results might have been satisfying or you realized that you have a job to do with optimization. 

Three paths:

SXL (Accelerated Path)
PXL (Medium Path)
F2F (Firewall Path/slowpath)

Goal: process traffic in most efficient path possible. (SXL->PXL->F2F). 

Real world: Most traffic in medium path (PXL). Why? "Deep inspection" by blades like Application/URL filtering, Threat prevention (IPS, Threat emulation, Threat extraction, Anti-Bot, Anti-Virus) and https inspection. Now with all these blades enabled (or some) how much is it really possible to accelerate through SXL in percentage? A nice way to find out that is to hear from CP administrators in this community. Also if you have some impressive stats tell us what your main tuning steps were. What is the output when you run this command?

                  fwaccel stats -s

Along with the output above it would be interesting to know this also:

Blades enabled: 

CPU cores: number of SND/IRQ cores and Firewall worker cores.

[Sergej_Dmitrije]

I think you should get 80%-90% through the PXL path.

I found two articles from Heiko Ankenbrand here in the forum that describe the paths well:

R80.x Security Gateway Architecture (Logical Packet Flow) 

R80.x Security Gateway Architecture (Content Inspection) 

Maybe this will help you!

Cheers,

Sergej

[HeikoAnkenbrand]

Hi Enis,

I agree with you, Timothy Hall gave a great presentation.

Enis, I don't think it makes much sense to look at other firewalls. Check Point firewall performance tuning is always an individual process.

The best would be if all the packets were going over the acceleration path (fast path). But if you have passive streming or active streaming in the game, you will use other paths.

PXL:

IPS (some protections), VPN (in some configurations), Application Control, Content Awareness, Anti-Virus, Anti-Bot and much more use the PXL path (medium path) if SecureXL is enabled.

The CoreXL layer passes the packet to one of the CoreXL FW instances to perform the processing (even when CoreXL is disabled, the CoreXL infrastructure is used by SecureXL device to send the packet to the single FW instance that still functions). When Medium Path is available, TCP handshake is fully accelerated with SecureXL. Rulebase match is achieved for the first packet through an existing connection acceleration template. SYN-ACK and ACK packets are also fully accelerated. However, once data starts flowing, to stream it for Content Inspection, the packets will be now handled by a FWK instance. Any packets containing data will be sent to FWK for data extraction to build the data stream. RST, FIN and FIN-ACK packets once again are only handled by SecureXL as they do not contain any data that needs to be streamed. This path is available only when CoreXL is enabled.

CPAS:

Several protocols uses CPAS, for example: Client Authentication, VoIP (SIP, Skinny/SCCP, H.323, etc.), Data Leak Prevention (DLP) blade, Security Servers processes, etc. In some scenarios, HTTP is also using CPAS, when IPS Web Intelligence protections are enabled. As for now, CPAS doesn't support accelerated traffic, this mean that each CPAS packet will be F2F.

Check Point Active Streaming active streaming allow the changing of data, we play the role of “man in the middle”. CPAS breaks the connection into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.). An application is register to CPAS when a connection start and supply callbacks for event handler and read handler. This will be a little different in R80.20.

---

Deep inspection consumed very much performance. Also https inspection consumed very much performance and others.

Here you can also find some interesting information:

How does the Medium Path (PXL) and Content Inspection work with R80 

New SecureXL path in R80.20 (CPASXL) 

Regards

Heiko

[ED]

Hi Heiko,

I know that it's an individual process but I was just curious about what others had managed to accomplish. With all these advanced blades enabled you realize that it's "impossible" to gain high percentage of the traffic in the accelerated path. It's more like make sure you have enough CPU resources to handle the traffic and try to tune the advanced blades and policy so that the packets expend minimum amount of CPU time in the medium path. Great info about PXL and CPAS!

[Kaspars_Zibarts]

I agree - it would be very hard to compare. We have over 50 gateways and the stats are all over the place depending on site and blades that are active. This VS may have half a million concurrent connections but no active blades apart from FW and IA.. so narly everything is accelerated and most CPU usage is on SXL cores

Accelerated conns/Total conns : 181616/228965 (79%)
Delayed conns/(Accelerated conns + PXL conns) : 1171/192361 (0%)
Accelerated pkts/Total pkts : 15763100601/16243830690 (97%)
F2Fed pkts/Total pkts : 387990089/16243830690 (2%)
PXL pkts/Total pkts : 92740000/16243830690 (0%)
QXL pkts/Total pkts : 0/16243830690 (0%)

[ED]

A good example that shows high percentage in SXL path without the advanced blades enabled. May I ask how is the CoreXL distribution of your CPU cores in a setup like this where you know that almost all traffic will be accelerated and you know that SND/IRQ cores will handle the accelerated traffic. How many SND/IRQ cores and Firewall worker cores?

[Kaspars_Zibarts]

I'm afraid this is one of VSes on VSX so it does not follow usual assignment.. On that particular node we have 4 SXL cores (not hyperthreaded) and interfaces use multiqueue. VS itself has 10 workers. But we will be increasing SXL capacity as it's already going over 50% and I prefer to keep it under that number to accommodate any sudden spikes in the traffic (we have 20Gbps trunk so it's easy to fill that one up  )

[HeikoAnkenbrand]

I do a lot of performance tuning for customers and copied a few passages from my training material.

1) This is a typical firewall with many blades on! Here the PXL path is used.

Blades: fw vpn cvpn av ips identityServer anti_bot ThreatEmulation mon
Cores: 16 (4xSND, 10xFWK, 2xfwd[Logging,...])
MultiQueue: on (4 Interface)
Interface: 4 x 10 GBit
Connections: approximately 500K, peek 700K
CPU: 50% over all cores

# fwaccelstats -s

Accelerated pkts/Total pkts   : 1052964458/159849848978 (0%)
F2Fed pkts/Total pkts   : 2764823456/159849848978 (1%)
PXL pkts/Total pkts   : 156032061194/159849848978 (97%)

---

2) This is a typical firewall with many blades off! Here the acceleration path is used.

Blades: fw vpn
Cores: 16 (8xSND, 6xFWK, 2xfwd[Logging,...])
MultiQueue: on (4 Interface)
Interface: 4 x 10 GBit
Connections: approximately 500K, peek 700K
CPU: 30% over all cores

Accelerated pkts/Total pkts   : 191956815617/194432772885 (98%)
F2Fed pkts/Total pkts   : 3767408762/194432772885 (2%)
PXL pkts/Total pkts   : 0/194432772885 (0%)

---

What else are tuning parameters for me?

- Interface cards 1G, 10G and 40GB > (MQ, Errors, interupt distribution, more or less SND's...)

- Blades + CoreXL > (more or less FW_Worker's, https inspection, deep inspection, PSL, CPAS, R77.30 VPN on FW_Worker_0 [R80.10 multicore VPN], CPU utilization,...)

- SecureXL > (NAT templates, Drop templates, Rule optimization for access tamplates,...)

- Connection Tabel > (many connections in TCP start state  + timeout, UDP virtual session timeout

- ClusterXL > (sync or not sync from services,...)

- Logging > (optimize logging in the rules,more or less fwd cores for logging,...)

- IPS > (Signatures with high performance impact,...)

- VPN  > (3DES or AES with NI [high-speed hardware encryption],...)

- SecureXL > (SAM card or Falcon card (R80.20 and above) inside,...)

- and and and

I can found 100 points more that can be optimized.

I think performance tuning is a very individual process for each firewall. Here you should first talk about what you want to accomplish on the firewall.

Regards

Heiko

[_Val_]

Just to clarify what PXL means.

On per packet basis, it is still the same SXL or F2F. PXL is a mixture of both, when SOME packets within a connection are accelerated and SOME OTHER packets go to FW workers for streaming.