Hi, > The biggest bottleneck I've found around number of users involves the > peer lookup at IKE authentication time. If you configure static traffic > selectors for each individual peer (as I do) then it's a linear search > across the set of KNOWN possible peer IDs.
While this is true, it only applies if you configure many individual ipsec.conf connections. ipsec.conf does not scale to hundreds of connections very well. But if you have a few connections only, this lookup doesn't have any impact. Alternatively you could use a single connection and write a better scaling plugin that narrows down traffic selectors for each peer. > I run 5000 clients with 1024b RSA pubkey auth on a 1GB VM guest of a > 2GHz core i5 machine and peer lookup is around 200ms on average. If IKE_SA lookup tuning [1] is configured properly, and your configuration backend does not slow down this process, much more is possible. I've tested configurations that served several hundred connection setups per second. The limiting factor is usually raw crypto, namely the Diffie-Hellman exchange. [2] has some numbers about public key operations. > Can anyone give me a rough idea of how many clients I can expect (say) > an Amazon EC2 large instance to handle. charon scales well to several ten thousand tunnels, but this depends all on your configuration and requirements. There is no fixed limit of concurrent tunnels, but each tunnel requires about 5-8KB of memory. > I found the integrated load test tool docs and intend to run this > tomorrow but I am not sure to what extent it emulates *real* users. It emulates real users just fine using different authentication methods. If you request virtual IPs, make sure to not actually install them (charon.install_virtual_ip = no), as it slows down the client significantly. Load-tester tests tunnel establishment only, but does not send traffic on those tunnels. > Secondly, I am investigating load balancing possibilities. Ideally I > would like a pool of (say) 4 strong-swans all of which can share a > load. I'm not sure if sharing load would mean user stickiness or some > hared state across nodes but source ip stickiness would be acceptable > I guess. Of course you can set up load balancing on a higher level, say DNS, or a dedicated load balancer. Each strongSwan then acts independently and handles just those clients that connect to them. If you need a failover mechanism, too, you could take a look at our HA solution [3]. It can share load, but also migrate clients transparently while the tunnel is active. It currently works for 2 nodes only. > Will this even work in a cloud (EC2) environment where the LAN IPs are > not under my control (unless perhaps VPC). HA depends on ClusterIP with a shared IP address. I don't know if this is possible in EC2. The switches must tolerate a multicast ARP for the shared IP, but usually this is no problem. Regards Martin [1]http://wiki.strongswan.org/projects/strongswan/wiki/IkeSaTable [2]http://wiki.strongswan.org/projects/strongswan/wiki/PublicKeySpeed [3]http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
