Clone layer

[Harald_Hansen]

I have worked with moving complex and big rulebases to smaller layers. My challenge is that copying rules between policy packages and layers is a very time consuming task, publishing takes hours, even on SSD storage.

It would be of help if I could work in parallell on multiple cloned layers in multiple sessions.

So I suggest a feature to clone layers, I'd guess this is feasible since cloning policy packages already is possible.

[Bob_Zimmerman]

It sounds like something is very wrong with your SmartCenter or MDS. Hours to publish?

I do my development work with a 2200 (dual-core 1.8 GHz Atom, and 4 GB of RAM) currently running R80.40 as a standalone. It takes about 30 minutes for CPM to finish starting after a reboot. Publishing takes maybe ten seconds.

[Harald_Hansen]

Clean R80.40 MDS installation, all policies are fresh or imported with the API and Python API integration. Anything very wrong in this installation has its origin at R'n'D.

I should probably clarify that publishing taking hours is out of the total. I copied 600 NAT rules and the publish took about 40 minutes, another session a bit later took 20 minutes for 400 Access rules. It all adds up.

[Bob_Zimmerman]

Oh! Okay. Last I checked, Check Point generally recommends publishing every 100 changes or so. Think of them as individual commits rather than branch merges. Only rarely should a single VCS commit be more than 50 new or changed lines.

[PhoneBoy]

That advice (publish after a 100 changes or so) is still the general recommendation.
Having to publish a large number of changes will definitely lead to longer publish times.

[Harald_Hansen]

Your post just confirms what I'm asking for in my original post. The problem when merging large rulebases is the need to copy and paste large number of rules. Going 100 at a time introduces the possibility of creating human errors as well.

[Bob_Zimmerman]

I've gotten a few object and policy creation scripts from Check Point's professional services group. They start with a login command, then usually about 70 'add ____' commands, then a publish. 70 more 'add ____' commands, and a publish. I've always built my own bulk creation scripts like that.

Yes, it sucks that it's slow to publish really big things as a single item.

[Harald_Hansen]

Bob, 

I know you're trying to be helpful here, though this discussion derails the purpose of my post. I have already imported the policy in question. It was done in batches using the Python API. The automated part of this workflow is over, now the tedious manual labour is due.

A solution I can see is to split the original rulebase into sections of 50-70 rules by adding temporary section titles, then copy those sections one by one. Though periodically even small sessions take forever to publish. 

Adding batch features, like cloning, moving/copying many rules in one operation, and other functions like these, would be incredibly useful in migration scenarios. This would also help Check Point customers improve their rulebases and start using all the new improvements that have been added.

Another example on batch flows; tag certain rules, then move all rules with this tag to the selected layer in a single operation/validation. I'll probably try to create something like that with the API, though within the 70 operations/session limit.

[Bob_Zimmerman]

I've been thinking about how I would do this in a general form.

1. Run a 'show access-layer ____ details-level uid' loop for the UUID of the layer you want to clone.
2. Run a dereferencer loop to resolve all of the UUIDs to object contents so they are management-agnostic. Replace the UUIDs in the rules with some sort of application-internal identifier.
3. For each object content, check to see if it exists on the destination management. If it does not, create it. In either case, record the UUID at the end. Every 75 object contents, publish.
4. Once you have all the object UUIDs, replace the application-internal identifiers mentioned in step 2 with the object UUIDs.
5. Create the layer with 'add access-layer' and record the UUID.
6. Use 'add access-rule layer _____ position _____' to add the rules to the layer. Again, publish every 75 rules.

If you know you only care about cloning layers within the same management, you can drop steps 2, 3, and 4. Adding a publish every 75 rules is easy enough. You just have an inner 'for' loop which counts up to 75, then an outer 'for' loop which counts by 75 and the value gets added to the inner loop value for the list index. The outer loop would set the session description, run the inner loop, and publish. I could probably script a same-management version of this process in a day.

Management-agnostic version would probably take two or three, as creating group hierarchy would be more complicated. The dereferencer in step 2 would be similar to the dereferencer in my ipsToRulesCP script. Step 3 would basically be an extension of what I do in my createObjectsCP script.