3815 and 3855 in same deployment?

[Janne K.]

As the title says. Is it possible to mix different SNS in the same deployment?

eg. having 3815 for only PSN and then having 3855 for PAN/MON/PSN?

[Rob Ingram · Accepted solution]

@Janne K. yes they can be part of the same cluster. Note, the 3815 as a dedicated PSN scales to 50,000 active endpoints compared to the 3855 which supports 100,000.

Refer to the ISE performance and scale guide for scaling information 

https://www.cisco.com/c/en/us/td/docs/security/ise/performance_and_scalability/b_ise_perf_and_scale.html 

https://www.cisco.com/c/en/us/products/collateral/security/identity-services-engine/secure-network-server-3800-series-ds.html

[Janne K.]

Thank you Rob,

The active endpoint is not my concern, but more having multiple persona run on a 3815.

Even cisco recommends to have atleast an 3855 in larger environments, having more processing, and having redundant ssd and all that.

[Rob Ingram]

@Janne K. well every customer environment and scaling requirements differ. You can have different models in the cluster, so it would depend on your scenario and whether you want the additional redundancy in the PSN. If budget allows, use 3855 for all nodes.

Cisco suggests:-

●      SNS-3815: Ideal for small deployments, optimized for performance and cost-efficiency.

●      SNS-3855: Configured for medium to large environments with robust redundancy in power supplies and storage. The SNS-3855 can be order in two configurations:

◦    Policy Services Node (PSN) only, with a single disk

◦    PAN and Monitoring and Troubleshooting Node (MnT), fully equip with four disks for medium deployments.

[Arne Bier]

The ISE BU has stuck to the same messaging since the early days of the older models of SNS. Those servers with spinning disk drives felt very slow. But what surprised me when I compared the CPU, MEM and DISK I/O of the basic SNS-3815 model, is that it outperforms the largest SNS-3600 and SNS-3700 servers - obviously not in max disk capacity, but times have moved on and Moore's Law still holds. But ISE BU has not changed their mind set and artificially limits what we can do with the SNS-3815 - in particular, if you could chuck 4 disk in there (and why not?) then you could have a very decent solution, rather than spend $100,000 more for the next model up ... just so you can add 3 more disks.

The SNS-3815 can be ordered with two power supplies.

64GB of RAM is a lot of RAM for a RADIUS server - let's face it - most of us use ISE as a RADIUS/TACACS+ server - those "super scalers" who need 1 million concurrent connections are at the far end of the bell curve. Concurrent endpoints is just a headline number - it doesn't tell you how much stress each session puts on the PSN - if it's a wired auth, then probably very little - but if it's a wireless EAP-TLS on roaming devices, then much more. There is a stark difference between a RADIUS server used for wireless (lots of activity) versus a RADIUS server used for wired auth (typically no re-auth ... just 48-hour interim accounting.

If you run ISE as a VM, take a look at REAL memory usage of your systems - in my case I consistently see that on a 25,000 concurrent connections PAN/MNT, the RAM usage is always less than 10GB. CPU on MNT seems much higher than on PAN/PSN. 

And let's not forget that if you create optimised Policy Sets, and keep an eye on your network auth Live Logs (i.e. track down and eliminate those pesky failed auths) then you can also reduce the load on your ISE. I use the ISE Reports to spot issues and then fix them. 

[ajc]

Great information Arne even though we are expecting to move into something called access manager solution.