R80.30 - A Good News Story

[MattDunn]

A few days ago I upgraded a customer from R80.10 to R80.30.  They are very pleased with the improvements in SmartView, and also shared this SNMP graph with me of the difference in gateway CPU utilisation.  I thought it was worth sharing with you all.  See if you can spot what time I completed the upgrade?  Quite remarkable! 😀

[MattDunn]

Hmm, it didn't include the picture!  Try again....

[HeikoAnkenbrand]

SecureXL works more effective here:-)

More see here:

Performance Tuning R80.30 Administration Guide

R80.20 and above:
- SecureXL has been significantly revised in R80.20. It now works in user space. This has also led to some changes in "fw monitor"
- There are new fw monitor chain (SecureXL) objects that do not run in the virtual machine.
- Now SecureXL works in user space. The SecureXL driver takes a certain amount of kernel memory per core and that was adding up to more kernel memory than Intel/Linux was allowing.
- SecureXL supportes now Async SecureXL.
- That's new in acceleration high level architecture (SecureXL on Acceleration Card): Streaming over SecureXL, Lite Parsers, Scalable SecureXL, Acceleration stickiness
- Policy push acceleration on Falcon cards

R80.30 and above:
- In R80.30+, you can also allocate a core for management traffic if you have 8 or more cores licensed, but this is not the default.
- Active streaming for https with full SNI support.

[Erik26]

Hi,

this is not our experience We needed to install TAKE_19 due to errors in HTTPS Inspection. After installation of TAKE_19 we experience Memory leaks and still receive "Internal system error in HTTPS Inspection (Error Code: 2)" 

So we think that if you use HTTPS Inspection you have to be careful. In performance we do not see a difference.

We run the firewall in cluster. See memory load and cpu (look at scale!) for both units. 

[Timothy_Hall]

Wow that is quite a drop.  Are you sure that the reported CPU loads are including total CPU time in all execution modes and not just kernel space (si,hi,sy) as reported by top command?  USFW is enabled by default starting in R80.30 regardless of kernel version, so traffic that cannot be fully accelerated by SecureXL is handled by the Firewall workers as fwk processes in process space (us).  Needless to say this change will cause a lot more CPU cycles to be expended in user/process space than before and may be skewing the graph.

It is also possible that you have a lot of fragmented traffic in your network, and prior to R80.20 fragmented traffic could not be accelerated at all and would always go F2F/slowpath.  That restriction was lifted in R80.20+ due to the extensive changes in SecureXL so that may account for the CPU drop as well. 

[PhoneBoy]

USFW is only enabled by default for specific appliances (ones with 40+ cores), not in general--at least not yet.

[Timothy_Hall]

USFW seems to be on by default in VMWare with 8 cores in R80.30, are the USFW enablement rules different for open hardware vs appliances?

[PhoneBoy]

Two different SKs clearly say it's on by default on R80.30 (sk93000 and sk149973).
I was just flat out wrong in this case 😬

[Timothy_Hall]

Yeah, thing is I distinctly remember reading or hearing that USFW would only be enabled by default on certain R80.30 gateways with a high number of cores (40+?) and not on all of them.  I uncovered that USFW is enabled by default in R80.30 during some research for an upcoming special project.  So it is not just you...  🙂

[MattDunn]

Interesting points, thanks 😀

[Garrett_Anderso]

Hello and thanks for the post.   

Have you had an opportunity to confirm the results from SNMP graph do indeed jive with other tools like SmartView, etc.   example:  use cpview (CLI) to validate SNMP results at individual point in time? 

The CPU consumption drop is eye-opening, but it would be good to validate this is not representative of kernel vs user space topics discussed elsewhere in thread. 

thanks -GA