Concurrent Sessions in VSX

[Matlu]

Hello, Mates.

In VSX the “concurrent sessions” feature applies across the board to the VSX box as such, or does it apply per VS that has a VSX?

What happens if the “concurrent sessions” reach their limit? Imagine that it is set to 1000, and that at certain times, the 1000 sessions are covered, the VSX/VS may crash? Or would there only be problems with the new traffic, until it is “leveled” again?

Is there any way to get a “report” or know how many concurrent sessions there were in the last 3 months? For example, to know how many concurrent sessions were reached in March, April, May, etc.

Thanks for your comments.

[Chris_Atkinson]

Connection limits are configured per-VS.

With R82 we actually increased the default limit.

Aggressive aging will activate.

See if the cpview history covers your need short of other methods snmp/skyline etc.

[Matlu]

Hi,

The "CPView History" should also be generated for each VS you need to evaluate right?
Or is it something that should be generated for each VSX box?

I have my VSX boxes hooked to a Zabbix where the resources are monitored.
I understood that this would be another alternative to “find” what I am looking for, using my monitoring manager (Zabbix)?

Thanks

[Chris_Atkinson]

Examples 

snmpwalk -v 3 -l authNoPriv -u user -A pass -n ctxname_vsid2 vsx2 CHECKPOINT-MIB::fwNumConn.0

CHECKPOINT-MIB::fwNumConn.0 = Gauge32: 54121

snmpwalk -v 3 -l authNoPriv -u user -A pass -n ctxname_vsid2 vsx2 CHECKPOINT-MIB::fwConnTableLimit.0

CHECKPOINT-MIB::fwConnTableLimit.0 = Gauge32: 299900

[Matlu]

Hello,
The value of the concurrent connections, when you create a new VS or when you want to modify the value of one that is already in production, is something that can be "adjusted"?
I can set it to any value, for example 30000?
Do you have to evaluate some characteristic before making this kind of application/change in the VS?

[Bob_Zimmerman]

You set the connections table limit on a VS the same way you do it on any other firewall. The only difference is VSs don't support automatic connections table scaling. Open the object, go to Optimizations (it's towards the bottom), and enter whatever value you want. When you hit OK, the management provisions the VS, but you need to push policy to the VS for the new limit to take effect.

The consideration for adjusting the limit is the same as for any firewall: how much RAM is available? All VSs run on the same OS, drawing from the same pool of RAM. This limit is to protect VSs from each other, so if one VS gets a volumetric DoS attack, a low limit prevents it from using all the RAM on the box thereby preventing other VSs from doing work. Size the total limit of all VSs based on the amount of RAM the system has. My personal overall limit for a system is about 250k connections per gigabyte of RAM, split any way you want between the VSs.

[Timothy_Hall]

Interestingly, R82 VSXNext does support automatic connection table scaling.  However, when I asked about the risk of one VS using up all the shared memory and interfering with other VSs when automatic is set, I never got a good answer about how that could be prevented.  So I would assume it is still a risk.

Also I assume your rule of thumb for 250k connections per gig of RAM is for IPv4 connections only?  I'm asking because tracking IPv6 connections consumes roughly twice the memory of tracking IPv4 connections.

[Bob_Zimmerman]

Yes, VSNext allows you to remove that bulkhead and allow all the VSs to compete for connections table space.

The 250k connections per GB of RAM is conservative enough I'm fine with IPv6 or whatever else as long as the machine has at least 16 GB of RAM. In more constrained environments, I do some measuring. Most of the deep inspection features consume processor time rather than RAM.

[Matlu]

Hi

What happens when the traffic exceeds the 250K you set up in a VS?

Is there a risk of the VS “crashing”?

Or it just keeps working but you can start to perceive anomalies in the traffic?

If the threshold you set for concurrent connections is exceeded, this can be ‘observed’ in the SmartConsole logs?

Or does one have to query the behavior at that time through the VS CLI?

Thanks for your comments

[Chris_Atkinson]

You can monitor the concurrent connections as indicated earlier via SNMP etc.

When aggressive aging engages you will see corresponding control logs in SmartConsole as a minimum.

If you are unfamiliar with aggressive aging please refer:

https://sc1.checkpoint.com/documents/R80.20/SmartConsole_OLH/EN/html_frameset.htm?topic=documents/R8...

[Timothy_Hall]

If the connections table reaches its maximum capacity when set to a manual size, further connections are simply killed with no logging until some space frees up.  If you happen to be running fw ctl zdebug + drop at the time, the dropped connections will be shown as dropped with reason "full connections table."  These drops will also be shown on the live cpview screen, Advanced...Network...Drops as "Capacity" drops if you happen to be watching.  If the PEAK# shown by fw tab -t connections -s is exactly equal to your connections table manual limit, you hit the limit at some point and lost some new connections.

This situation typically manifests as poor Internet browsing performance, where some HTTP/HTTPS connections initiated by a web browser fail, while others succeed.  Web sites may load slowly, not load at all, or only partially render.

[the_rock]

Ola bro,

You just do this like you would on regular fw, via smart console object.

Andy

[Chris_Atkinson]

Correct it can be adjusted to your liking.

In the Traditional VSX mode, the default value for concurrent connections in the Virtual System object was increased from 15,000 to 50,000 (Optimizations section > Capacity Optimization page).

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