SSL-VPN load test on MAG

[jan_devos_]

Hello,

We want to do a ramp-up of the # of concurrent SSL-VPN connections on MAG, and measure performance impact. Caused by MAG, but also by the rest of the perimeter (edge router, FW ...).

Unfortunately there is no test tool on the market for SSL-VPN tunnel creation to a Device under Test (MAG in this case) + sending user traffic across the tunnel.

Therefore, we consider a next-best approach to create many concurrent iPSec tunnels + send user data tru them. This scenario is perfectly possible with the tester. But it is based on two assumptions:

1) The limiting load/performance factor on the MAG is the encryption/decryption.

2) En/Decryption is performed by the same logic (processes, tasks, circuitry, algoritms ...) on the device regardless whether ipsec or ssl.

Can you confirm these two assumptions?

[Kita_]

These assumption are correct, but you will want to consider if the device support ssl acceleration or not.  If ssl acceleration is enabled, this will offload the encryption and decryption to the hardware acceleration card.  If ssl acceleration is not supported or disabled, this will be done via the software.

The results will differ depending if SSL or ESP mode is utilized and the distribution of packet sizes.  Ideally, ESP with larger packets can pump more data through the SA device than SSL mode with small packets.

[jan_devos_]

Thank you for this reply. I an not sure I fully understand.

You state a dependency on SSL Acceleration Enablement. Is SSL acceleration enablement a configuration option of SA Services? REsulting in whether or not downloading en/de-cryption to the HW of the Service Module (SMx60)?

And if so, is this 'SSL Acceleration' valid for both ESP and SSL transport?

I found SSL Accel. is only available on SM-360 in MAG-661x. Is there a max. # of concurrent ACCELERATED connections (I found max. concurrent SSL-VPN connections is 20000, but I would wonder if all are accelerated.

[Kita_]

SSL acceleration is only a configurable option in the SM-360.

In regards to load testing for L3 tunnel, it will depend on two major factors:

• Distribution of packet sizes
• Distribution of ESP vs SSL tunnels

Depending on the distribution, this will affect the max throughput the device can handle.  Since all end user will not be sending the same amount of data at a given point in time, this does not easily equal to specific number of concurrent users.

For example, if you have a lot of idle tunnels, we may be able to increase the number of concurrent users.  However, if we have active tunnels with a large amount of data being sent, we will see a decrease in the number of concurrent users.

[spuluka]

Load testing tools are great for finding absolute limits for capacities but they do not really help with determining how many users can my connection type support. Load testing involves sending lots of connections and data but it is really hard to get a load tester to look like the varied mix of users you actually get connecting in a system like this.

The issue is that generally users don't connect and blast steady streams of data. There are hills and valleys and the heights and depths are different per application. So you essentially have multiple variable streams from your users throughout the connection period that are going up and down all the time.

I would try the following method to get a better handle on your user count capacity.

Analyze your user base and try to determine how many differet kinds of actual load you have in the mix. Hopefully this will at least roughly correspond to how you have roles setup. The different applications and usage will have different stresses on the system capacity by both volume and frequency of the data coming in. Assign the user groups into low, medium and high usage categories (the actual numbers don't matter just releative to each other).

Look at system utilization over a couple weeks or a month. Find the peak on each day. Then get the number of each type of connection active at the time. i.e. 23 low; 15 med; 44 high.

Use this data to calculate a rough value of usage then for low medium and high as many times with different combinations of days. Generate at least 10 answers. Then average the results.

Now you have an approximate usage value for each type of user. Now you analyze you employee growth agains the usage categories. How fast will the low, medium and high numbers rise as an aggregate.

From the spec sheets you know the limits of your hardware. So now you have a pretty good approximation of how many users your specific system and userbase can handle.

[jan_devos_]

Thank you for explaining your approach and PoV. I can agree for the largest part of it.

However, I have some remarks:

1) You mention 'system utilization' as performance indicator. I see Internet Access BW utilization as evenly important. And the overall Perf. Indicator resulting from several underlying perf. indicators is the End-User experience or transaction response time. We should (find a means to) measure those as well.

2) You suggest regression analysis of a number of samples with known System Utilization % and known #users cat1,

#users cat2, #users cat3. Which should lead to :

#U_Cat1 * SystemUtiliz%_Cat1 + #U_Cat2 * SystemUtiliz%_Cat2+ #U_Cat3* SystemUtiliz%_Cat3 = System Utiliz %

Extrapolation of #U_Cat1,2,3 to obtain future SystemUtiliz% assumes linear behavior. Which is not sure. In the areas of 'heavier' load, adding more users could cause the system to behave non-linearly.

So, testers push the devices under test to their limits, but evenly important, identify above which thresholds non-linear bahavior starts.

[spuluka]

1) You mention 'system utilization' as performance indicator. I see Internet Access BW utilization as evenly important. And the overall Perf. Indicator resulting from several underlying perf. indicators is the End-User experience or transaction response time. We should (find a means to) measure those as well.

Yes, bandwidth utilization is a key metric and this can usually be optained from your ISP portal ifyou don't have an internal monitoring system collecting that data.

2) You suggest regression analysis of a number of samples with known System Utilization % and known #users cat1,

#users cat2, #users cat3. Which should lead to :

#U_Cat1 * SystemUtiliz%_Cat1 + #U_Cat2 * SystemUtiliz%_Cat2+ #U_Cat3* SystemUtiliz%_Cat3 = System Utiliz %

Extrapolation of #U_Cat1,2,3 to obtain future SystemUtiliz% assumes linear behavior. Which is not sure. In the areas of 'heavier' load, adding more users could cause the system to behave non-linearly.

Yes, I use this as an approximation not an absolute. My overall point is you cannot get an absolute number of user limit no matter what you do. But in my opinion analyzing your ACTUAL user community at PEAK NORMAL usage (to a bunch of testers pretending to work). Is a better method to get a closer approximation than a peak load external tester.

this does involve educated estimates and is an approximation. But even if you get an absolute limit from an external load tester the number of these connections will have little to no relationship to your actual user activity anyway and have limited value to estimate the number of user you systems can support.