R80.20 SecureXL drop template support

[Hugo_Marques]

Hi,

I was reading the "Performance Tuning Administration Guide R80.20" and pass by something that made me think about some upgrades that i will need to do on the next's months to R80.20 and push them forward until this is supported, at least on 2 of them that have a good amount of traffic droped by the SXL.

The drop template feature on SXL still not supported.

Does anyone know when it will be supported? mid 2019?

Regards

[PhoneBoy]

Further, when you issue the command fwaccel cfg -b on, you don't get a "not supported" error, it just silently fails.

However, I suspect Drop templates won't provide as much of a benefit in R80.20 as they did in previous releases.

This is because initial packets in R80.20 don't need to go F2F to be inspected.

[PhoneBoy]

Update: Drop Templates are supported in R80.20.

Further: the comment in the docs about fwaccel cfg -b not being supported is erroneous and will be removed.

Doesn't explain what I saw, but if you're having issues, I recommend opening a support ticket.

[Hugo_Marques]

Dameon Welch-Abernathy, Thanks for your reply's.

I wasn't able to test it, but I will in the meanwhile on my lab environment.

Dameon Welch-Abernathy wrote:

(...)

This is because initial packets in R80.20 don't need to go F2F to be inspected.

One more thing can you point me to where can i find the initial packets route, infografic or text described?

[PhoneBoy]

This doesn't exactly show what I'm talking about, but:

• R80.x Security Gateway Architecture (Logical Packet Flow) 

Prior to R80.20, the design of SecureXL required the initial connection to be F2F so the SecureXL template could be created.

This was also required because certain low-level checks could not be done in kernel space.

Now that we've moved most of SecureXL into userspace, most of those checks can be done entirely there without taking the full hit of going F2F.

[Timothy_Hall]

SecureXL Drop templates are supported in R80.20, however traffic matching a drop template still goes to a firewall worker initially (thus causing load on the worker), and is then offloaded back to SecureXL who drops it.  Unfortunately this behavior kind of defeats the purpose of drop templates in the first place which is keeping the drop overhead off of the workers, and had me really scratching my head when I first saw it.  The hotfix for this doesn't appear to have been mainstreamed in any of the Jumbo HFAs that I can see, so it is probably not in R80.30 either although I haven't checked yet:

sk150812: High CPU when traffic is dropped by fw_workers

[Efrat_Meir]

Hello all,

I would like to share some info on R80.20 ‘first packet flow’ in general and drop templates in particular which will hopefully clarify the situation.

“Drop templates” is an important and valuable feature and is supported in R80.20.

The logic of drop templates is still enforced in SecureXL level (practically in the dispatcher).

Upon first packet of new connection and drop templates enabled, the dispatcher enforces drop templates before dispatching the packet to FW worker.

The packet is dropped at this point if needed, and hence,  the load is reduced from the FW workers.

I will additionally emphasize that R80.20 indeed changed the logic of “Accept Templates”.

Up until R80.20 the accept templates were enforced in SecureXL and from R80.20 are enforced in the FW worker.

Essentially, if the packet is not dropped by drop templates, the dispatcher forwards the packet to the FW worker in order to open a new connection either from accept template if exists, or from rulebase.

The new connection is then offloaded to SecureXL to continue its processing from there.

As a common practice, we suggest to enable drop templates from Smart Console.

The bug discussed here is a CLI parameter for enabling/disabling drop templates which was not supported in VSX and a fix for it will be introduced in next R80.20/R80.30 JHFs.

I would be more than happy to share additional data if required.