04-04-2019 09:45 AM
Hi,
Apologies if this was answered before, but I couldn't find anything related with my searches.
Can someone please confirm if having PSN's with multiple roles (e.g. RADIUS+SXP, or SXP+PXG) in a fully distributed model is officially supported?
Thanks!
Solved! Go to Solution.
04-04-2019 10:58 AM
04-04-2019 11:18 AM - edited 04-04-2019 11:40 AM
Short answer is that it's definitely going to work, but I feel Jason's link for the performance and scale document fails to address the broader discussion needed with your question. There are no direct scaling numbers for a shared PSN in a distributed deployment. We know that a dedicated PSN supports 40k-100k active endpoints in this model (depending on template), but if you add other services such as SXP or pxgrid to these nodes then I would want to account for that load.
There are environments where SXP load has to be handled by it's own nodes. Same goes for pxgrid, I have deployments where 3595's are maxed out doing their pxgrid roles. I think it's reasonably fair to assume that in most environments a dedicated 3595 PSN would handle the functions that a standalone node typically would. 20k endpoints, x number of pxgrid and SXP etc. This becomes a much more complicated topic when you know you're going to be tight on scale.
Testing all the variations of dedicated PSN's with shared roles would be a nightmare. I think you just have to build in the flexibility and be prepared if the design needs the extra nodes. SXP is a good example in that the recommendation is to run it on a dedicated PSN due to the load it can have, at the same time, I know many deployments where their SXP load is low and it's fine sharing a node with other roles.
04-04-2019 10:58 AM
04-05-2019 04:41 AM
Hi Jason,
As before, apologies if I missed it, but I can't see any reference to shared services PSN being supported in a fully distributed deployment, either in the performance and scale article or in the Cisco Live presentation.
In fact, I would go as far as to say the two documents actually suggest the opposite: only dedicated roles per appliance are supported, as the performance figures for shared services PSN's (again, for fully distributed deployment) are either missing or explicitly called as "N/A".
The only exception to this is RADIUS+TACACS, which is mentioned, but my query was more general than that.
And, as Damien correctly anticipated, my question has a broader scope: if shared services PSN's are indeed officially supported, then, I think we need to also get official guidance on how to "size" the performance of such PSN's (per shared service), for design purposes.
I understand and agree that it would be hard to try to come up with specific, testing based, performance figures for every combination of shared services you could have on a PSN.
That said, however, I think the need for someone to be able to properly size an ISE solution is also legitimate, as long as the design of that solution is officially supported (thus, my original question).
Given the above two statements, if I am to make a suggestion, I would think that coming up with a set of approximate (and conservative) rules of thumb on performance scaling when services are shared on a PSN would be something do-able on Cisco side and usable for design purposes on the consumer side.
So, something like:
* 3655 appliance with RADIUS + SXP - approx. 60% normal RADIUS scale for that appliance + approx 20% normal SXP scale for that appliance
04-04-2019 11:18 AM - edited 04-04-2019 11:40 AM
Short answer is that it's definitely going to work, but I feel Jason's link for the performance and scale document fails to address the broader discussion needed with your question. There are no direct scaling numbers for a shared PSN in a distributed deployment. We know that a dedicated PSN supports 40k-100k active endpoints in this model (depending on template), but if you add other services such as SXP or pxgrid to these nodes then I would want to account for that load.
There are environments where SXP load has to be handled by it's own nodes. Same goes for pxgrid, I have deployments where 3595's are maxed out doing their pxgrid roles. I think it's reasonably fair to assume that in most environments a dedicated 3595 PSN would handle the functions that a standalone node typically would. 20k endpoints, x number of pxgrid and SXP etc. This becomes a much more complicated topic when you know you're going to be tight on scale.
Testing all the variations of dedicated PSN's with shared roles would be a nightmare. I think you just have to build in the flexibility and be prepared if the design needs the extra nodes. SXP is a good example in that the recommendation is to run it on a dedicated PSN due to the load it can have, at the same time, I know many deployments where their SXP load is low and it's fine sharing a node with other roles.
04-05-2019 04:54 AM
Hi Damien,
Thank you for the response!
Yes, I expect that configuring shared services will technically work (I do that regularly in the lab), but that doesn't mean it is also officially supported.
And, as per my answer to Jason, you guessed my intentions correctly: the goals with this discussion thread are to, first, confirm official support (for shared services) and, second, determine a method for sizing an ISE solution using shared services PSN's, method that is consistent and stands against scrutiny even from the most official authorities out there (like TAC, for example).
Also as stated, I don't expect an exact set of figures or mathematical formula for every combination, but some rule of thumb guidelines should be enough.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide