R80.x - Performance Tuning Tip - SecureXL Fast Accelerator (fw ctl fast_accel)

[HeikoAnkenbrand]

The Fast Acceleration (picture 1 green) feature lets you define trusted connections to allow bypassing deep packet inspection on R80.20 JHF103 and above gateways. This feature significantly improves throughput for these trusted high volume connections and reduces CPU consumption.

The CLI of the gateway can be used to create rules that allow you to bypass the SecureXL PSLXL path to route all connections through the fast path.

Tip 1

Use this function to exclude IP's or networks from deep inspection.

Picture 1

Here you can see the complete packet flow in detail : R80.x - Security Gateway Architecture (Logical Packet Flow)
I will update the document  to this new function in the next few days.

Feature Attributes:

• Configured from the gateway's CLI.
• Can be turned On / Off, Off is the default.
• Rules can be added / deleted by demand.
• Configuration (State / rules) survive reboot.
• Maintain rule hit count (does not survive reboot).
• Every configuration change done by the user is logged in $FWDIR/log/fw_fast_accel.log file.

Feature Usage:

fw ctl fast_accel <option>

Option	Explanation
add	Add a connection
delete	Delete a connection
enable	Set feature state to on
disable	Set feature state to off
show_table	Display the rules configured by the user
show_state	Display the current feature state
reset_stats	Reset the statistics collected by the feature
--help/-h	Display help message

To create fast_accel rules, read more in this sk156672 - SecureXL Fast Accelerator (fw fast_accel) for R80.20 and above.

[Morten__]

What about VSX support? Is it fully supported in VSX? And how is it enabled in VSX - per VS? Or is it enabled in VS0 and then configured per VS?

[Wolfgang]

@Morten__ 

yes, it's supported with VSX. You have to enable and define rules for each VS.

Wolfgang

[Kaspars_Zibarts]

Has anyone managed to get it to work on VSX? Trying hard but keep getting 0 hit count. R80.30 T219.

It's enabled on a specific VS

there is definitely traffic between those hosts

[_Val_]

What does "fw -vs <vsid> ctl get int fw_fast_accel_is_initialized" say?

[Kaspars_Zibarts]

[Expert@vsx:0]# fw -vs 10 ctl get int fw_fast_accel_is_initialized
fw_fast_accel_is_initialized = 1

[_Val_]

Also, does the same traffic cross any other VSs on the same box?

[Kaspars_Zibarts]

actually no, it's one physical interface to another on the same VS

[Kaspars_Zibarts]

sorry have to blur out actual IPs but you will have to trust that they match fast accelerator rule 🙂

[_Val_]

I understand. Please go to TAC for more analysis on that.

[Kaspars_Zibarts]

Thanks @_Val_ will do!

[Wolfgang]

@Kaspars_Zibarts  We are using fast_accel rules on R80.40 take 118 with VSX. No problems seen. Traffic hits the rules and connections are really faster then without (database replications and VMware-backup).

[Kaspars_Zibarts]

Did you need to enable it on VS0? Or just actual VSx you want to use it on?

[Wolfgang]

We enabled this in one specific VS only.

[genisis__]

Silly question is Take 118 stable and has there been any improvement in performance with this?

I got told by a TAC engineer that Jumbos upto Take 102 should be migrated to 118 as there are a number of stability issues fixed in this.

[genisis__]

Kaspars - works for me.  We are running R80.40 with JHFA102

 

[Timothy_Hall]

If the traffic has to go F2F for some reason, the fast_accel will not work.  However your fwaccel conns output suggests that this traffic is not in the F2F path, because if it was it wouldn't show up at all in the output.  Your first fast_accel rule is for port 2029 while the actual traffic is port 2049, but I assume it should still match the second fast_accel rule.

I have a hazy recollection that NFS traffic cannot be handled directly by SecureXL (same as CIFS) and that may preclude using fast_accel in this case.  Can you try doing a fast_accel for some port other than 2049 or 445 that is not F2F path and see if that works? 

[Kaspars_Zibarts]

Thanks Tim! Especially for spotting the typo! I'll need to try again haha And I'll play around with my other VSX that runs R80.40 just to make sure I'm setting up all correctly

[HeikoAnkenbrand]

Article  with new pictures and text revised for R80.40.

[Dale_Lobb]

I also have had issues getting fast_accel to work with some traffic.  I've had a TAC case open for a few weeks on this.

First, there is a direct conflict in statements made in sk156672:

1) "The Fast Acceleration feature lets you define trusted connections to allow bypassing deep packet inspection."

2) "Fast Accel enforces only rule base that does not require deep packet inspection.

I've been told by TAC that I need to have a global exception for the traffic for all inspection blades before the traffic can be added to the fast_accel table.  What I do not understand is: Why is this necessary?    If I totally bypass inspection by all blades, why is the traffic not then  carried by the SecureXL SND cores?  Why does it still show up on my FW worker cores if there is no inspection involved?  Why do I even need fast_accel then?

[genisis__]

First I heard about a global exception! I've not done this and it works for me.

Also this would only apply for new connections not existing.

[Wolfgang]

@Dale_Lobb 

I never heard about...

"I've been told by TAC that I need to have a global exception for the traffic for all inspection blades before the traffic can be added to the fast_accel table."

With a fast_accel rule you create such an exception. Only source, destination and service will be inspected for a connection defined with fast_accel (firewall-blade only).  None of the blades from the whole ThreatPrevention family, none of the "inspection settings", no deep inspection for protocols....

Only the early taking effect features like AntiSpoofing, traditional Geoprotection, SAM-rules, PenaltyBox etc. are checked too. 

[Timothy_Hall]

When it comes to the fast_accel feature, TAC's recommendation is somewhat valid but I think some of the details got glossed over.  Fast_accel does not bypass inspection by all blades, it basically instructs the Firewall Worker/Instance to offload the connection into SecureXL if possible, which reduces the depth of inspection possible due to the limitations of SecureXL, but is not a full bypass in the traditional sense.

Here is my understanding, I don't think this has changed in the R81+ releases but I could be wrong. 

You can set up a fast_accel rule for whatever you want, BUT the rule will not have any effect (and show zero fast_accel rule matches) if: 

1) The traffic must be handled in the F2F path due to a special protocol handler (think FTP control connections) or elements of Threat Prevention (TP) are forcing F2F due to a "Critical" performance impact signature being applied to the traffic.

2) The traffic must be handled in the CPAS path for active streaming, SecureXL cannot do this on its own and it must be handled on a firewall worker.  Classic example would be HTTPS Inspection.

So what I think TAC is recommending here is to make sure that the traffic isn't getting forced into the F2F or CPAS paths by TP which will preclude the traffic getting handled by fast_accel.  Unfortunately a TP exception is not the way to do this, as an exception does not change what path the traffic is handled in; it only changes the final decision (Prevent vs. Detect vs. Inactive).  

The right way to do this is to match the traffic to what I call a "null" profile at the top of your TP policy.  The null profile is a TP profile with all five TP Blades unchecked.  If you have multiple TP layers (not common) the null profile rule must be at the top of all of them, or a more restrictive TP rule in another TP layer could trump the null rule and force deeper inspection anyway.  Note that this null profile approach may not be necessary at all depending on how your TP features are configured, but I can see how TAC might recommend something like this as a first step.

There are many other special situations where the connection cannot be offloaded into SecureXL for one reason or another, and there have been some recent threads here at CheckMates mentioning it.

[Kaspars_Zibarts]

I'm getting mixed bag of results atm. For example I wanted to accelerate our proxy outgoing connections which would be "plain" HTTPS, we don't use TLS interception, so it's a pure port/IP filtering. And new connections would be established all the time (i.e. it's not one long existing ongoing connection). But no luck there.

Then I was able to get some results on my own laptop but not 100%. 

I tried both R80.40 T102 and R80.30 T219.

Still trying to understand.. what really stops it from working. Lack of time though is preventing me to investigate it properly 😞

[genisis__]

Long shot but did you try with R80.40 T118?  When I last spoke to TAC they told me there where issues with T102.

Also with encrypted protocols we have an exception as well, as we are not doing any inspection on encrypted protocols, exception was added for all TP Blades.

[Dale_Lobb]

  I am using R80.40 T118, and am still having problems accelerating some traffic.  These rules has been in place for weeks:

  The 2nd rule started working after I enabled a global TP exception for the traffic, making all blades inactive for it.  I tried the same for the first rule, but it does not seem that anything I do can get the fast_accel feature to work. 

  BTW, the 1st rule is for internal Citrix traffic over tcp/2598, which is what our NetScalers use to encapsulate Citrix ICA traffic destined for internal Citrix servers.

[Dale_Lobb]

Hi @Timothy_Hall , thanks for the explanation.  I'm not sure I completely understand, though: What is the operational difference between a "null profile" rule with no blades checked and a global exception with all blades checked but specified as "inactive".  The global exception gets applied to all TP rules, so would that not prevent the traffic from being inspected by all the blades?

[Timothy_Hall]

Traffic matching a global exception will still cause it to be inspected in whatever path it would have otherwise, and will usually take at least the Medium Path (PXL) but may end up in CPAS or F2F depending on how TP is configured.  Even though there could be a global exception for all blades, the TP policy is checked before any exceptions therefore regular inspection must take place first prior to looking at exceptions and the fast_accel may not work depending on what path the traffic ended up in.  All exceptions do is change the final decision rendered after inspection (Prevent, Detect, even Inactive).

On the other hand a TP null profile rule matching the traffic specifies immediately that no inspection whatsoever is required by TP, and when the first packet of the new connection arrives and is accepted, the worker may offload the connection directly into SecureXL for full acceleration if no PXL is needed.  The fast_accel just helps encourage that process for PXL path traffic.

[Kaspars_Zibarts]

@_Val_ or @PhoneBoy  - maybe you guys could arrange a session with someone from R&D who could fully explain technical details? It is indeed welcome feature and wold help us address many situations - long term and short term fixes when we run into problems. But would be nice to have full understanding so we can have fairly good knowledge about situations when it will work and when it won't?

[_Val_]

Not sure I understand the question. Feel free to reach offline with more details. I believe you have both our emails 🙂