Due to some network infrastructure changes, the traffic passing through my internal FW (a Checkpoint VSX virtual system) started to suffer latency and packet loss.

No change had been made to the Checkpoint VSX, but for any reason, since that network changes, Checkpoint was not processing the traffic succesfully.

Performing a top on the VSX appliance containing the active “INTERNAL FW” virtual system showed the following:

Checkpoint VSX top - virtual system


Press “1” after launching “top” command

By default: 1 virtual system -> 1 instance (1 CPU core)
And the CPU core was so high it was overloaded.

Checkpoint VSX top - single thread virtual system


With “threads view” on (pressing shift+”H”)
Thats the only thread the virtual system 2 launches.

To solve the problem, I got better performance after moving some rules due to packet processing acceleration (see “fwaccel stat” command), but it wasnt enough.

So, it was neccesary to create more instances of the virtual system so that more CPU cores would be assigned to it:

Inside the “CORE XL” section of the virtual system properties, i incremented the “Number of virtual system instances” from 1 to 4.

Checkpoint VSX increment virtual system instances CoreXL

A warning regarding the downtime it will produce raises

Downtime warning when incrementing Checkpoint VSX virtual system instances

During the process, 4-5 pings of traffic to affected networks were lost.

Applying Checkpoint virtual system configuration

After applied, latency / packet loss was completely solved.
Checking the threads again showed the newly created instances:

Checkpoint VSX top - multiple thread virtual system

No cores with a high rate 🙂