Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Dezso_Gesztesi
Participant
Jump to solution

Accelerate specific traffic with SecureXL

Dear All,

Unfortunately I am facing with the following issue. Nowadays on one of our firewall the CPU utilization is very high. Here is some output from the firewall statistics:

// CPU utilization, during the load but it can be higher, not just 80%

Num of CPUs:      2

      CPU      Used

        0       80%

        1       37%

// The Total traffic

Totals                 Mbps           pps

TCP                      85        14,852

UDP                      13         3,512

Other                    34         5,748

// The protocols

Protocol               Mbps           pps

TCP:https                55         9,679

Other:-1                 34         5,748

TCP:http-alt             21         3,863

UDP:ipsec-nat-t           9         1,915

TCP:http                  7         1,180

UDP:twrpc                 2           958

UDP:cleanerliverc         1           255

TCP:53959                 0            63

UDP:50366                 0            63

UDP:5246                  0            31

The Other:-1 traffic is hugh amount of etherIP traffic

// fwaccel stat output

Accelerator Status : on
Accept Templates   : enabled
Drop Templates     : enabled
NAT Templates      : disabled by user

Accelerator Features : Accounting, NAT, Cryptography, Routing,
                       HasClock, Templates, Synchronous, IdleDetection,
                       Sequencing, TcpStateDetect, AutoExpire,
                       DelayedNotif, TcpStateDetectV2, CPLS, McastRouting,
                       WireMode, DropTemplates, NatTemplates,
                       Streaming, MultiFW, AntiSpoofing, Nac,
                       ViolationStats, AsychronicNotif, ERDOS,
                       NAT64, GTPAcceleration, SCTPAcceleration,
                       McastRoutingV2
Cryptography Features : Tunnel, UDPEncapsulation, MD5, SHA1, NULL,
                        3DES, DES, CAST, CAST-40, AES-128, AES-256,
                        ESP, LinkSelection, DynamicVPN, NatTraversal,
                        EncRouting, AES-XCBC, SHA256

// fwaccel stats -s output

Accelerated conns/Total conns : 41/2851 (1%)
Accelerated pkts/Total pkts   : 15216180/46515424 (32%)
F2Fed pkts/Total pkts   : 9724592/46515424 (20%)
PXL pkts/Total pkts   : 21574652/46515424 (46%)
QXL pkts/Total pkts   : 0/46515424 (0%)

// In cpview I see that this Other traffic goes via F2F, thus this can raise the CPU utilization

F2F Reasons

Reason                         #Packets      % out of Total
pkt is a fragment                 2,263                  0%
ICMP miss conn                   36,741                  0%
TCP-SYN miss conn             1,043,260                  1%
TCP-other miss conn              27,385                  0%
UDP miss conn                   751,171                  1%
other miss conn                      34                  0%
ICMP conn is F2Fed               16,246                  0%
TCP conn is F2Fed               271,550                  0%
UDP conn is F2Fed                15,449                  0%
other conn is F2Fed          49,669,199                 94%  <<< Every etherIP goes via F2F
TCP state viol                   85,780                  0%
out if not def/accl               3,343                  0%
partial conn                     11,990                  0%
PXL returned F2F                417,188                  0%
general reason                       17                  0%

I would like to ask, is there any way to accelerate the etherIP traffic to avoid the high utilization? Or is there any document about those packets which cannot be accelerated?

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

I assume the "other" traffic is not TCP or UDP.

That traffic does not get accelerated.

You can see what doesn't get accelerated here: SecureXL Mechanism 

View solution in original post

0 Kudos
6 Replies
PhoneBoy
Admin
Admin

I assume the "other" traffic is not TCP or UDP.

That traffic does not get accelerated.

You can see what doesn't get accelerated here: SecureXL Mechanism 

0 Kudos
Dezso_Gesztesi
Participant

From the mentioned sk:

"ICMP, GRE, ESP, CIFS or any other protocol different from TCP and UDP" - So it seems that I cannot accelerate the EtherIP traffic and yes, neither TCP nor UDP traffic. Do you have any recommendation/suggestion, how can I decrease the CPU utilization in this case? Unfortunately I cannot redirect this traffic through another device because every traffic goes through this FW. Worst case, I assume that I have to replace the firewall to a bigger one.

0 Kudos
PhoneBoy
Admin
Admin

As the traffic cannot be accelerated, and you've only got two CPU cores, there's not much you can do here.

I definitely suggest a larger gateway with more cores. 

0 Kudos
Dezso_Gesztesi
Participant

In this case, I'll choose the FW replacemenet. Thank you for the help!

0 Kudos
Timothy_Hall
Legend Legend
Legend

As mentioned in my book, 2-core firewalls are between a bit of a rock and a hard place.  By default you will have a 2/2 split of SND/IRQ to Firewall Worker cores, which means the two cores are serving overlapping functions.  You can try disabling CoreXL from cpconfig which will result in a 1/1 split.  Doing so may help or it may hurt, just get a good benchmark for CPU load before trying it.

 

Also be aware that R80.10 ongoing Jumbo Take 177 has introduced the ability to force certain trusted traffic to be handled by SecureXL no matter what and completely skip the Medium and Firewall Paths.  This capability has been around for awhile on the 41k-64k scalable platforms (sk113080: 60000 / 40000 Appliances - SecureXL Fast Accelerator (sim fastaccel)) and has now been ported into the main train of code.  The command is sim fastaccel and you can read more about it here:

 

sk139772: SecureXL Fast Accelerator (sim fastaccel) for Non Scalable Platforms

 

This new feature is present in the Take 189 GA edition of the R80.10 jumbo HFA.

 

The big application I can see for this is allowing high-speed LAN-to-LAN traffic (such as backups between a DMZ and the internal network) to be able to take the SXL path, regardless of any other inspection that is called for in your configuration which would normally invoke the extra overhead of PXL or F2F.  Because this traffic will be treated as trusted, it is very important to perform a thorough risk analysis prior to configuring this feature.

 

Note: This capability does not appear to be present in the R80.30 EA or R80.20 gateway code yet, at least that I can find.

 

--
"IPS Immersion Training" Self-paced Video Class
Now Available at http://www.maxpowerfirewalls.com

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
HeikoAnkenbrand
Champion Champion
Champion

Nice info Timothy.

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events