We had an issue today when about 3500 people connected remotely using anyconnect. We are usually around 1500-2000 on a normal day but due to the snowstorms, it jumped. People started reporting slowness and things taking generally a long time. From the networking team, we were told the network links were at 90%. We previously had roughly 5500 working remotely last February with no reported issues but the only difference is that they were on the VPN Client. We have moved to AnyConnect since then. I know there's more fulltime telecomuters and VOIP being used but there's still 2000 less people than last year. Is there anything in an AnyConnect session that would account for this? Unfortunately I don't know what the utilization was last February to compare but I know people didn't have issues. Any help would be appreciated. Obviously we'll be studying this to see what happened.
Since nobody responded yet, here's my 2 cents: With DTLS enabled ("svc dtls enable" in the group-policy, normally enabled by default) you should get performance comparable to IPsec.
So other than to verify that DTLS is used (basically SSL over UDP instead of TCP), I can only suggest to:
- try and find out (I realize this may not be trivial) if the traffic pattern is different (i.e. if the users are now using more or different applications, e.g. higher bandwidth or smaller packets).
- consider traffic shaping, in order to match the ASA's egress speed to your actual link speed (not sure if that will help in this particular case).
Thanks for the reply. It turned out to be a software push that was miscoded and was download/running on many machines every day even while on VPN. I had to ask this question because I was in a pinch. We didn't really think anyconnect was the reason but people were pointing at it since that was the obvious thing we changed in the environment since last year.