R81.20 - Performance Tuning Tip - Maestro Fastforward

[HeikoAnkenbrand]

Maestro offers with R81.20+ a interesting performance features in the future:

Maestro Fastforward (Fast Accel) - Significantly Improved throughput and latency for trusted connections. Maestro Fastforward offloads accept or drop policy rules to the Maestro Hyperscale Orchestrator level for hardware acceleration.

To support high-speed, high-volume transaction environments (e.g. digital trading), Maestro now offers accelerated data paths for higher throughput and lower latency based on predefined rules (“Fastforward”).

How it works:

Policy

The Administrator marks desired rules to be offloaded to the Orchestrator by giving the applicable rule names a specific prefix (the prefix is configurable). During policy installation, the applicable rules are translated into Access Control Lists (ACLs) and offloaded to the Orchestrator to be enforced on the hardware level.

The offloaded rules are translated into stateless ACLs. Therefore, the offloaded rules are enforced without full stateful inspection capabilities. For TCP connections, for Accept Rules, the SYN packets are sent to the Security Group and Processing is transferred to the MHO via the API for the second packet.

Routing

To accelerate a trusted connection on the Orchestrator at the Layer 3 level (routing), the Orchestrator has to know the networking information of the Security Gateway in order to send the packet through the correct outgoing interface to the correct next hop. The Orchestrator must have the same view of the topology as the Security Gateway. Therefore, the feature replicates the Security Gateway's / Virtual System's routing topology to accelerate traffic at the Orchestrator level. In addition, this logic occurs at the hardware level and is very robust.

Restrictions in version R81.20:

- Fastforward acceleration is not supported for directly connected subnets.
   The networks must be connected via router in R81.20.
- Management interface is not supported.
- When accelerating traffic through a bond interface, egress traffic goes out only thrugh one subordinate interface (for each MHO).
- For UDP connections the Security Group does not generate logs (For TCP connections the Security Group generates a
   corresponding log)

Supported deployment types:

- Singel site, dual site
- One or two MHO's on a site
- Gateway or VSX  (the configuration is for each Virtual System) mode

Enable Fastforward:

1) Connect to the Maestro Security Group via gclish.
2) Configure a prefix for the Access Control rules
     > set maestro fastforward rulebase-prefix enable prefix fast_rule
     > set maestro fastforward state on
3) Connect with SmartConsole to the Management Server and create a Access Control rules with the prefix you configured earlier.
    If your prefix is set to “fast_rule”, for the policy rule names use: “fast_rule_1”, “fast_rule_2”, and so on.
   

More read here:
R81.20 Admin Guide -> Fastforward 

[genisis__]

Would I be correct in say that the total concurrent connections would be number of gateways divide by 2 within the Security Group?

[Timothy_Hall]

Not quite.  As mentioned in the new Maestro Expert R81.10 class now available at many ATCs, the published maximum number of concurrent connections associated with a certain gateway model and its installed RAM must be cut in half for Maestro operation, due to the way Hypersync works.  However if one were to assume that all traffic was NATted through the Maestro security group it would now be 25% of the published maximum.  This is unavoidable and is not dependent on how many gateways are part of the security group.

Example: The Security Gateway appliance 16200 data sheet states that for this gateway with the standard 48GB of RAM, up to 8 million concurrent connections are supported when acting as a regular gateway. With the maximum 128GB of upgraded RAM on a 16200 acting as a standard gateway, up to 32 million concurrent connections are supported.  With fully-loaded RAM in this model,  16 million concurrent connections are supported in a Maestro security group, but only 8 million concurrent if one were to assume all connections were subject to NAT which would not be unrealistic at the Internet boundary.

As the course states, it is strongly recommended to install the maximum amount of RAM if possible on gateways that will be used for Maestro.  It would take awhile to explain why Hypersync causes this effect, but essentially for HyperSync to incur such low overhead and an amazingly miniscule 1% performance penalty for each new gateway added to the security cluster, the big tradeoff is higher memory consumption to keep track of everything.

[genisis__]

Is this the same for R80.20SP as well?  

are there any ATRG papers I can review as I can find this information on the checkpoint site.

[Timothy_Hall]

Yes I believe the same concurrent connection limits apply to R80.20SP, I don't think Hypersync has changed much fundamentally R80.20SP to R81.10.

The source for the maximum number of concurrent connections under Maestro was taken from this article which is in the Partner community section, and you therefore may not be able to access it:

https://community.checkpoint.com/t5/Partner-Community/Maestro-POC-Best-Practices/m-p/112401

The new official Maestro Expert R81.10 ATC-based course has all this information in the courseware, which pulled together many, many sources for its content.  I know this because the current Maestro Expert R81.10 course offered by ATCs is based on a private 2-day Maestro class I myself created for a very large customer, then Check Point acquired the material and adapted it for the official course we have available today.  The class is the best single source for all the Maestro material out there as of R81.10 because to create the class I had to read through, absorb, and compile the course material from all these sources:

270+ SK articles
300+ CheckMates Maestro-related threads
15 Slide decks from Maestro-based presentations
1000+ pages of official documentation

My company Shadow Peak is not able to run the official Maestro classes going forward due to hardware limitations, so the above is not just a sales pitch for my own benefit.  Give the Maestro Expert R81.10 course material a look, you won't be disappointed and you'll want to attend the class.  @Anatoly @Lari_Luoma care to comment?

[Lari_Luoma]

@Timothy_Hall  cannot comment on the material you mentioned as I haven't seen it. We have our own 2 day Maestro workshop and training in Professional Services that we have successfully used to train customers, partners and our internal staff. Benefit of the  this class is that it is constantly being updated and can be customized with customer specific needs if necessary.

[Lari_Luoma]

@genisis__ 

Let's talk about the concurrent connections in Maestro.

Disclaimer:
Calculation below is not 100% accurate because of different traffic shapes and sync configurations (not all connections are synchronized, very short lived connections etc.)

DS = Data Sheet number

1 SGM = DS
2 SGMs = the same as with 1 SGM due to active/backup connections synchronizing
3-n SGMs = DS+(n-2) x DS/2

Example:

With maximum memory 7000 appliances has 16 Million connections as a data sheet value for concurrent connections.

With five 7000 appliances in the security group the calculation would be approximately:

16 x (5-2)x16/2 = 40 M

Maximum concurrent connections for 5 x 7000 appliances would be thus about 40 Million.

[minnien]

Thanks Lari for the detail explanation. 

How about a security group with mix and match appliance models? Let's say 3x7000 + 2x6200? Should I use the average or the lowest number (DS number of 6200) in the formula? 

[Lari_Luoma]

With mix and match you define weights for each appliance to make sure different types of appliances are equally loaded. To calculate the performance numbers I think the best way would be to use the above formula for each appliance type, so for 7Ks and 6Ks independently.