SecureXL UPPAK Mode for Lab?

[Timothy_Hall]

Similarly with what happened to the Firewall Worker Instances being moved out of the kernel into processes (called USFW), SecureXL is in the process of being moved out of the kernel as well (called UPPAK).  Currently, only systems with a Lightspeed card and the new 9000 series will be utilizing UPPAK mode, while all other gateways will continue to have SecureXL in the kernel for now (called KPPAK).

Question: Is it possible to force UPPAK mode for testing/lab purposes only on a system that does not currently support it?  My question is specific to VMWare gateways utilizing the vmxnet3 driver.  This may actually not be possible at all since it appears UPPAK extends its tendrils into the Gaia networking driver code in ways not seen before (sk181564: Differences using the 'ethtool' command with SecureXL Kernel Mode (KPPAK) and User Mode (U...) as well as shifting away from an interrupt-driven approach to "poll mode", which dramatically changes how CPU resources are utilized by the SND cores (sk180299: Linux commands report high CPU Load Average when SecureXL works in the User Space (UPPAK) ...).

As I mentioned UPPAK for the moment may require the presence of certain hardware or network drivers that can't be readily simulated in a virtual machine, so this may simply not be possible at the present time.  Tagging @Val for an R&D assist.  Thanks! 

[HeikoAnkenbrand]

If you change the Firewall mode from User Mode (USFW) to Kernel Mode (KSFW), then SecureXL mode changes from the User Mode (UPPAK) to the Kernel Mode (KPPAK) and vice versa.

More read here:
100G_Ports_AdminGuide 

You can change the current SecureXL mode between Kernel Mode (KPPAK) and User Mode (UPPAK):
1) Run
# cpconfig
2) Enter the number of the Check Point SecureXL option. The menu shows the current SecureXL mode.
3) Enter the number of the "Change SecureXL Mode" option.
4) Exit from the cpconfig menu.
5) Reboot

If you want to test this under VMWare, you can create a 19000 appliance from a VMWare system in /etc/appliance_config.xml file and after rebooting, manually load out-of-tree modules using the insmod command "insmod </PATH/TO/MODULE.ko>". If the kernel module from Nvidia is not installed, SecureXL will not be started in user mode;-)

It is also possible to set the parameter "SxlIsUsermode" with the "cpprod_util" to "1" in the firewall start script.

I didn't want to write more detailed information in the community about exactly how it works.

I have changed it in the LAB. However, as the network drivers do not correspond, there are many unwanted side effects.

Without side effects, you can only test it on real appliances:
19000, 29000, MLS LightSpeed, QLS LightSpeed

[Timothy_Hall]

Thanks Heiko, I encountered the same driver dependency issues and it looks like UPPAK isn't currently compatible with the vmxnet3 driver (or of course the ancient e1000 driver which will be deprecated for R82).  I did manage to actually panic the gateway at boot time by trying to force UPPAK enabled under the hood.  We will see if R&D has some secret switch or patch that will enable compatibility with vmxnet3, but for now I have put in a request to my local SE team to see if they can get me a loaner 9000/19000/29000 from the demo pool.  Thanks!

[HeikoAnkenbrand]

I think that PPAK will run in user mode for all appliances with R82.x... in the future. It makes no sense for me to develop kernel software and user mode software parallel.

Perhaps @Dorit_Dor  can also answer this question.

[Gera_Dorfman]

UPPACK is going to be our only mode in the future. 

Right now QLS appliances and Force appliances are using UPPACK.

Regarding older appliances / virtual machines and open servers UPPACK support  - still not fully supported / tested . 

[HeikoAnkenbrand]

@Gera_Dorfman 
It also makes sense to only use UPPACK in future and not to develop both twice.
Thanks for the info.

[PhoneBoy]

Right now UPPAK is only for QLS (i.e. those specific cards).
While I can't say for certain, I suspect it is not in a mainstream release yet, thus not something you can enable.
I would expect this in R82.

[Thomas_Eichelbu]

Hello Team, 

last two days i had the honor of installing two 29200 appliances ... 
so far so good, but when i checked the limitations of that performance beast i was more then shocked....
i stumbled over this then when trying to activate IoC Feeds and it was not working, checking ioc_feeder.conf was leading me to the SK´s of that limiations ... 

"[73535 4108466048]@XXXXXXXXXX[4 Dec 14:21:11] CIOCCustomFormatParser[891] ::write_line: [WARN] observable type IP/IP Range is not supported in uppak mode with HW offload"

https://support.checkpoint.com/results/sk/sk179432

https://sc1.checkpoint.com/documents/Appliances/100G_Ports_AdminGuide/Content/Topics-100G-Card-AG/Kn...

Thats really gruesome!!
so all SXL related things are not really working?
Traffic statistics are not  supported.
uninstalling a HFA is strictly forbidden ... surely because of driver updates of the NIC´s
BFD is not working, really hits us hard, the mentioned customer heavily relies on dynamic routing.

Is there are timeline when Quantum Force with UPPAK is full featured again ??

[Chris_Atkinson]

On balance KPPAK might be necessary in the interim if you need BFD etc depending also on what other blades are used.

[Thomas_Eichelbu]

Hello, 

yes indeed a valid point, but would you buy a Ferrari and use tires which do not handle the speed a Ferrari can go?

[Chris_Atkinson]

Of course hence why I mention the blade mix.

This has a bearing on the degree of benefit provided by the SXL mode / Smart NIC as it currently stands.

[Timothy_Hall]

This is related to the use of DPDK in releases going forward to improve performance as summarized here: R82: Parallel Processing Based Packet Flow

My understanding is that DPDK allows packets to be sent directly between the NICs and process space (hence UPPAK & USFW), without invoking the significant overhead of crossing the Linux kernel/userspace boundary for every packet that is not fastpath.  It also moves away from interrupt-based processing to a poll mode which makes all SND CPUs run at 100% constantly, but reduces latency and overhead.  There is also some offloading of operations into the NIC hardware involved to improve performance as well.

Overall this is a major change that is on-par with the complete rework of SecureXL in R80.20 in anticipation of the failed Falcon initiative, which indeed did cause some hiccups for awhile.