On 06/04/17 15:37, debbie10t wrote: > Company A has 1,000 vpn users and (for what ever reason) they reboot > the server every 24 hours. They experience the slow down because all > their vpn users are permanently connected. They all connect at once. > This patch is not trying to address the initial connect it is trying > to address the subsequent reneg's all happening at once.
This is not what --reneg-sec is about. --reneg-sec does not control the initial connection. What you want here is a randomized initial connection delay when client have lost connection to the openvpn server and needs to do a reCONNECT. That is an entirely different feature than reNEGOTIATION of established tunnels (which --reneg-sec targets). However, randomizing --reneg-sec will improve the situation *after* the initial connect congestion, once the first renegotiation round starts. At this point in time, things will start to spread out. But I emphasize again, --reneg-sec have never tried to solve randomizing of the _initial_ connect step. -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
