Inline Layers Question

[antsvett3]

Hi Everyone,

We are starting to use inline layers and I'm researching best practices etc. The one thing I can't find is does it matter where to start inline rules when are are starting in an ordered policy and how it affects performance. Any feedback is appreciated.

Thanks,

Anthony

[Chris_Atkinson]

What might be beneficial for migration from one policy construct to the next in a given environment and what performs most optimally aren't necessarily the same thing. To understand this further it may help to review the policy matching mechanism i.e.

https://community.checkpoint.com/t5/Management/Unified-Policy-Column-based-Rule-Matching/td-p/9888

Also Tomer previously consolidated some good links on Layers here for reference:

https://community.checkpoint.com/t5/Management/Layers-Best-Practices/m-p/21023

[Sorin_Gogean]

hi,

as we went through same exercise few years ago, the way I read/understand  "The one thing I can't find is does it matter where to start inline rules when are are starting in an ordered policy and how it affects performance. " would be 

Is there any problem if my inline layer rule is after some ordered layers ?!!??!!? 

If that is the question, then I can say that you will combine ordered with inline layers, when building your policy .

In our case we moved from ~300-400 lines ordered layer to ~250 lines (in total) using inline layers .

ty,

[Timothy_Hall]

When writing my book I did some limited research about the performance of using solely inline layers with one blade enabled in each (Firewall, APCL/URLF) vs. using a single layer inline that invoked the Firewall blade in the top/parent rules (simple services only), then invoked APCL/URLF in the sub-layers via categories/applications.  For an identical policy goal, the resulting compiled Unified policy for each approach looked extremely similar and I wasn't able to detect any difference in rulebase lookup performance between the two.  So my basic conclusion was that ordered vs. inline is about the same as far as gateway performance especially due to the new Column-based matching, but if anyone from R&D would like to elaborate on this topic that would be great.  @PhoneBoy 

My general philosophy is that if you still have the straight ordered layers (one blade per layer) which is what you end up with after a R77.30->R8X upgrade and they are working well for you, there is no urgent need to spend the time converting it into a fully unified inline policy.  This is especially true in my opinion if the policy is very large.  It doesn't seem to make a difference in gateway performance, but a properly-constructed inline policy can be easier to understand and work with.

However if you are creating a brand new policy package from scratch for a new gateway/site, I'd strongly recommend using fully inline layers from the get-go and possibly security zone objects as well.  This is a piece of cake to do when starting a policy package from scratch, and will be much easier to manage in the long-term as the policy size grows.

[PhoneBoy]

Where I think you might see a performance improvement with inline layers is in dealing with services that aren’t SecureXL friendly.
Basically, you can bury them in an inline layer so the rest of the policy will template.

[Alex-]

Another aspect with ordered layer vs inline layer is that with the former, you need to accept a flow in both Network and Application  layers (or any other combination) which could double your logs for the same traffic if you log everything. With inline layer, logs are matched only once in either a "top level" network rule or the inline one, reducing log traffic.