Cisco ISE PxGrid Role on ISE and appliance models

[techno.it]

I am designing a distributed deployment of Cisco ISE for a customer. The customer have HQ and 4 Remote Sites.

Remote sites are very critical to the client. Each site have 2500 endpoints and connected to HQ over IPSec. I have the below proposal to the client

2x PAN, 2 x PSN, 2 x MNT for HQ

2x PSN at each remote site.

Customer will also want to integrate ISE with DNAC which is installed at HQ

My questions:

- Can I propose to install PXgrid role on PSN to discuss the number of nodes.

- Which ISE Appliances are preferred for such distributed deployment ?

Any other suggestions and valuable inputs for the design are most welcomed.

[Arne Bier · Accepted solution]

Hi @techno.it 

Since you're already going with a fully distributed deployment (separate PAN and separate MnT), and if budget is not a problem, then the suggested approach is to dedicate two nodes just for pxGrid. You can make those VM's to reduce the amount of appliances required. But if budget is a concern, then enable pxGrid on the two nearest PSNs (in the HQ I would assume).

For the distributed nodes I would recommend

VM in the HQ - for PAN and MnT I would choose the 600GB OVA. If you MUST use hardware appliances then the SNS-3655 is the way to go. Same for any other ISE nodes that live in the HQ - assuming of course you have a well run VM Infrastructure.

VM in the remote sites - but if hardware is mandated, then of course the SNS-3615 is perfect for the job. Not sure why you need two appliances in each site? Why not make the RADIUS/TACACS+ fail-over server use one of the PSNs in the HQ instead? A single SNS-3615 will be quite overspec'd and used as the Primary server 99.999% of the time. When you patch or have a failure for a short while then you can use a PSN over the WAN. But if site survivability is key (i.e. PSN failure MUST be covered by another on-site PSN then sure, another SNS is required).

VM's require a VM license (Small or medium) - factor that into your Bill of Materials.

VM's are so much easier to work with and also never go obsolete ... less can go wrong (HDD, cables, fans, CIMC, etc.) - ISE VMs will be live happily ever after, assuming the underlying virtualization layer is well maintained.

Use Cisco Smart Licensing, especially if using VMs. No need to created license files etc.

[techno.it]

@Arne Bier  Thank you so much for providing valuable inputs. Project is overbudgeted, so I suggested to enable PxGrid on HQ PSNs.

Remote sites critical, as you mentioned  "site survivability is key" hence, I will keep 2 x 3615 PSN

At HQ, For PAN and MNT, I would use Physical as primary and Standby as virtual. What about using 3615 SNS at HQ as well for PAN ,MNT & PSN

What is the bandwidth required for sending logs to MNT over WAN ?

[Arne Bier]

I think given your numbers, if the number of  concurrent sessions in total were to exceed 10,000 then the SNS-3615 would not be as per the Cisco recommendation for PAN and MNT. See the Sizing page For details. But chances are that it would still work well because 4 x 2500 sessions is your anticipated max? The challenge is that if each PSN starts hammering the MNT nodes With syslogs , they would be under some strain.  
not sure about wan bandwidth. It might also be in that page or elsewhere on this Community forum. 

[techno.it]

Every remote site including HQ will have its own PSN, and the estimated concurrent session to each PSN would be between 3000-5000 sessions.

HQ PSN will not be a backup for any remote site. So, I would 3615 as PSN.

So the concern is only with PAN and MNT nodes, whether to choose 3615 or 3655

[Arne Bier]

According to the Cisco sizing/scaling guidelines, SNS-3655 is the right choice for MnT and PAN. Under the covers the 3655 allows can handle the higher number of data structures (ie RAM) and the necessary disk space for logging. I also think you might run into TAC support issues if you went with 3615 if in future you had performance issues. They’d question your product choice. Rather go with 3655 from day one and be ready for growth. 

[techno.it]

@Arne Bier Thanks for the help, Appreciate it.