ISE | Virtual Instance Sizing

[hanguye3]

Hi bros,

We have customer with 6000 active users and they consider to choose VM instance or physical appliance to deploy. i have sizing question on the VM Instance and need your advice on the queries below:

- Cisco ISE Virtual Machine Small can have 16GB RAM and up to 6 CPU cores: can it handle 6000 active users?

- can we install this VM with more resources like 32Gb RAm and more CPUs?

Highly appreciate for any quick response.

thanks in advance.

Br,

hainm

[Damien Miller]

32 GB is not a valid configuration for an ISE VM. The supported VM deployments for 2.2/2.3/2.4 are either a 3515 (16GB, 12 vcpu, 12000 MHZ) or 3595(64 GB, 16 vcpu, 16000mhz).  

To give you a direct answer, you can support 6000 active endpoints on 3515's.  Here is the scaling guide that answers this question. https://community.cisco.com/t5/security-documents/ise-performance-amp-scale/ta-p/3642148

Maximum number of concurrent sessions in a Hybrid deployment  (PAN & MnT on a single node and dedicated PSNs)	5,000 for 3415 as PAN+MnT 10,000 for 3495 as PAN+MnT 7,500 for 3515 as PAN+MnT 20,000 for 3595 as PAN+MnT	Same
Maximum number of concurrent sessions in a Standalone deployment  (PAN, MnT, and PSN personas all on a single node)	5,000 for 3415 10,000 for 3495 7,500 for 3515 20,000 for 3595	Same

[Arne Bier]

I often tell my customers that if they split the PAN and MnT into separate VM's, then a SNS-3595 PSN can handle 40,000 concurrent sessions.  Is that number still correct?

Is 40,000 concurrent sessions perhaps too much load for a single box, versus spreading the load over two or four smaller PSN's? 

If you're dealing with a centralised design ( DC-1 and DC-2 ) and you put all your PSN's in the DC, ... AND ... you want to avoid a load balancer in your design (i.e. PSN <= 2 ), then using the SNS-3595 and loading it up to the eyeballs is an option.

[Damien Miller]

I'm always skeptical of scaling numbers, I feel marketing people grab a number and run with it.  We recently had the unfortunate opportunity to test how many active connections a single 2.4 3595 vm PSN can take.  Three of the four VM's behind one of the LB's were killed by the server team, we ran just under 50k active on the remaining vm in that DC for a day and a half.  We considered shutting it down to force failover but no one reported any issues.  Authentication latency did rise from the usual 40 ms to around 200ms, CPU only went up ~5%. 

I imagine every deployment would be different.  In this case it is primarily wired/wireless eap chaining/eap-tls/mab/mschap/peap, minimal guest portal usage, no posture, and not the dhcp profiling target. I suspect that most of the latency came from the load put on AD, ISE appeared unphased by the event.

From a scaling perspective we haven't had auth issues, just mnt issues.  Wish we could have stayed on 2.1. 

[Arne Bier]

That's very useful feedback.  I also think that a machine with 64GB RAM and all those MHz of CPU power can handle such a load.

I remember the days when we used to quote the number of cps (connections per second) or logins per second on service provider radius platforms (e.g. Cisco Prime Access Registrar).  Those boxes were much more light weight than ISE and handled a massive load.    Imagine a radius server handling 500 unique clients performing EAP authentications in a sustained manner.  In most enterprises, we don't see 500 logins per second on a single Radius server.  Those quoted 20,000 sessions in ISE documentation are probably accumulated over a long period of time, and nothing much happens on ISE until the NAS sends an Accounting update. ISE just needs RAM to store all of these sessions.  And the latency is potentially related to higher disk activity (since you mentioned the CPU only rose by 5%) - I doubt that a 1Gbps LAN connection was the bottleneck.

It's a different situation though, if those 20,000 clients were forced to re-auth SIMULTANEOUSLY due to a NAS failure - then perhaps ISE could be bombarded with a lot of cps and collapse all over the place.

[hanguye3]

Many thanks for your feedback, bros!!!