On 06/04/17 14:49, David Sommerseth wrote: > 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. >
Which is exactly what I said .. >> This patch is not trying to address the initial connect it is trying >> to address the subsequent reneg's all happening at once. Regards ------------------------------------------------------------------------------ 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
