R82 VSXNext Capacity Optimization - Automatically?

[Timothy_Hall]

So it would appear that R82 Virtual Systems created under VSXNext now support the setting "Automatically" under Capacity Optimization...Calculate the maximum limit for concurrent connections.  In traditional VSX only the setting Manually was allowed, and the administrator had to set a hard limit on the number of connections for that VS.  My impression was this was to ensure that a single VS could not get blasted with a huge number of connections (DoS or something) and consume all available memory on the VSX appliance, thus impacting the other VS's on the same appliance.

So now that it appears Automatically is allowed in R82 VSXNext, is there some built-in mechanism to avoid this situation?  Some kind of fair memory allocation strategy to VS's for the connections table?  There doesn't seem to be any documentation about this.  Thanks!

[PhoneBoy]

I suspect this is a side effect of the fact there isn't a distinction between "regular gateways" and "virtual systems" with VSnext, i.e. because they use the same type of gateway object now.
How it handles memory allocation in this situation...can't say.

[ShaiF]

Hi @Timothy_Hall,

There is no hiding restriction in VSNext. By default each VS get unlimited connections.

Customers who would like to restrict connections limit for VS in VSNext can easily do it as it was SGW (Same UX). Go to the VS object under "optimizations" and move from Automatically to their preferred number.

The reason for change is that looking on our past customers incidents we saw many cases where customers faced outages due to the fact connections limit were not adjusted to the grow of the company.

Our DDos protections make sure no connections will be open for the suspected tuples.

Regards,

Shai.

[Timothy_Hall]

Got it, thank you!

[Timothy_Hall]

Hi @ShaiF can you please elaborate on this statement:

"Our DDos protections make sure no connections will be open for the suspected tuples."

So if in a R82 VSNext environment if all VS's are set to "Automatically" and a connection-oriented DoS attack is launched against one of the VS's, what is to keep that VS from consuming an excessive amount of memory thus affecting other VS's on the same system? 

You mentioned DDoS protections (I assume you mean fwaccel dos), are these enabled by default in a VSNext environment?  What would be the best practices for a VSNext environment where some or all VS's are set automatically?  I would assume minimally making sure Aggressive Aging is enabled, but how should the Advanced settings for this protection be optimized for this kind of environment?  Any recommendations for fwaccel dos settings beyond the defaults in an "automatically" VSXNext environment?  Thanks!

[ShaiF]

HI @Timothy_Hall ,

Since VS in VSNext behave as regular SGW the ddos protection default is the same (not activated). As in SGW, as far as I'm familiar, it is always best practice to enable protections.

As i mentioned, Currently, Customers which prefer protecting single VS from consuming the entire memory over having outages and drops since they legitimate reached the limit they set , can can always go to any desired VS Object and set the connections limit.

On our future roadmap is to have more strict resource control per VS where you can limit the entire memory each VS will be able to consume.

Regards,

Shai.

[JozkoMrkvicka]

Was something changed in R82 in regards of CoreXL for VS ? By default, 1 IPv4 and 1 IPv6 core is assigned for each VS.

[Chris_Atkinson]

It's not discussed here if it was:

https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_RN/Content/Topics-RN/Software-Chan...