Load Sharing - R80.30

[Tommy_Forrest]

I am preparing some documentation to configure our 3 node internet edge firewall cluster to support load sharing in case of emergency.  The intention would be to not leave load sharing configured indefinitely.  Hopefully for no more than a week or two.  At which time, the emergency subsides or management buys us some shiny new gear.

This is just one but a few mitigation steps I'm planning for.  Others include disabling IPS and Identity, those will happen before we enable load sharing on this cluster.

The cluster is on R80.30 HF Take 140.

Looking at the ClusterXL Admin Guide, there is a warning on page 20 (this warning is repeated on page 22, 25, and 26) -

"The R80.30 ClusterXL does not support the Load Sharing Modes (R80.20 Known Limitation MB-30)."

Then it goes on to note that "To support the load Sharing modes, you must follow sk162637".

Looking at sk162637 it notes that you must modify your Windows system variables by adding ENABLE_CLUSTER_LOAD_SHARING_R80_20.

And then it goes on to note that the management server must have cpm.sh modified.

This is very confusing.

What does my Windows variable entries have to do with anything?
Does following sk162637 imply that load sharing is supported on R80.30 even though the admin guide explicitly and repeatedly says it isn't?

[G_W_Albrecht]

Load Sharing is not supported with R80.30 together with the IPSec VPN Blade - that is the current limitation that makes LS unusable for most environments. sk101539 adds some more limitations from old.

Your Windows variable entries make it possible to select LS in Dashbaotd, that is all...

[Tommy_Forrest]

The option to select load sharing is already in my dashboard and I can select it.  And I don't have the environment variable set on my workstation.

The document is very confusing and unclear.

[PhoneBoy]

Without the variable set on the workstation, as I recall, when you try and save that setting on a R80.20/R80.30 gateway, it will fail with an error.
Likewise, if you don’t edit the startup script to set the required environment variable, it will fail.
The SK should clarify this.

[Dorit_Dor]

In order to support Maestro, we changed load sharing of VPN to maestro way and it meant that we ”broke” VPN load sharing on main train. At first we documented it and blocked it saying that we do not support ANY load sharing.

Later we realized that many need load sharing without vpn. So we enabled load sharing in the ui but kept it documented as no support for vpn and block vpn outside of the ui like phoneboy explained. 

SO to sum up - you can do load sharing but without VPN. 
the vpn support is under work but we cant release it until its rock solid so its still not ready.

The fact that its less this way, was clear to us but we had clear tradeoff between “blocking a lot” and “ui warning” - initially we were more restrictive (blocking) and it was clear while it blocked too many (more cases than necessary). Now, we changed the tradeoff, are allowing all supported cases but users who try VPN have less clear blocking (which was the reason we were restrictive to begin with). 

[joerg_weller]

If customers can no longer use primary functions from R77.30 in R80.x and have to invest in maestro, we can buy another firewall now. And some vendors are even cheaper (Fortinet, Paloalto,...) and they can do that.

[Dorit_Dor]

Before taking this tradeoff we checked that the amount of users that actually use load sharing with vpn is in the very low single percentage. This was in tradeoff of significant uptake of maestro customers that enjoy close to main train code. 

As also indicated,  we plan and we are working to return this functionality... as i indicated few times in the past, if its critical for you or your customers (concrete customer usage) you can talk thru local sales with the solution center and get commitment date for  delivery of reimplementation.  

in fact, If we will start to see more cases like this, it will be easier for us to give it higher priority 

Dorit 

[PhoneBoy]

Maestro is ultimately a better load sharing solution than can be achieved with appliances alone.
That said there are still some use cases where traditional Load Sharing with ClusterXL still makes sense.

Like Dorit said, we are planning to bring Load Sharing with VPN back in the future.
If it's a priority for you and/or your customers, engage with your local office.

[Tommy_Forrest]

Thanks guys.

Like I said, we don't intend to turn on load sharing unless it becomes an emergency as we send all of our employees home due to the virus.

And yes, I completely agree that Maestro is the better solution.  However, that requires a tremendous amount of capital not only from a $ perspective but also FTE perspective and it cannot be rapidly deployed from a scratch solution.

After calls with Diamond, we determined that load sharing wasn't there in 80.30 but was brought back in hotfix take 76 (we're on take 140 for those particular gateways).  The documentation on this is very poor and should be updated.

[Dorit_Dor]

To save problems/confusion etc, ...

the load sharing in 76 is the load sharing without vpn. the load sharing with vpn isnt released  

[Sergei_Shir]

(1) The note in the ClusterXL Administration Guides was updated:

Important:

• Load Sharing modes are only supported with the required R80.30 Jumbo Hotfix Accumulator. For instructions, see sk162637.
• To upgrade a ClusterXL that works in a Load Sharing mode from a lower version to R80.30, follow these steps in the same maintenance window:
  1. Upgrade the ClusterXL to R80.30.
  2. Install the required R80.30 Jumbo Hotfix Accumulator. For instructions, see sk162637.

These changes should become visible approximately 2 hours from posting this reply (at 20:00 UTC/GMT +2)

• R80.30 ClusterXL Administration Guide
• R80.20 ClusterXL Administration Guide

(2) The sk162637 will be updated as well during this week.

[hboogie]

try this friends : 

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...