Showing results for 
Search instead for 
Did you mean: 
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.


ISE v1.2 AuthC Policy Processing Performance

Hi guys,

We have ISE v1.2 running in the lab at the moment, and are intending to first deploy a Proof of Concept at two sites before a global deployment across four data centers and 150 Tier 1/Tier 3 sites.

We will be deploying ISE for wired 802.1x for domain devices and MAB for trusted non-802.1x capable and guest devices

ISE will be performing RADIUS proxy for 802.1x to Microsoft NPS servers using RADIUS Server Sequences. (I know ISE can do this but this was the design choice made by the business to meet certain requirements...)

- DC sites will have a pair of PSN nodes (and separate PAN and MNT nodes in the top-level DC) and a pair of NPS servers.

- Tier 1 sites will have a local PSN node and NPS server.

- Tier 3 sites will use the regional DC PSN nodes and NPS servers.

In order to ensure authentication requests are sent by ISE to the nearest NPS server, we are testing specific RADIUS Server Sequences that are called by specific Authentication policies that match a location (plus 802.1x auth) condition.

We have quite a lot of these rules - 40 so far in the lab.

My question is, has anybody built out a similar design, and what performance impact does ISE suffer by trawling through a long list of Authentication policies? How can we monitor this? I have optimised the Tier 3 sites at the top of the list (as these sites have no local ISE and suffer heavy latency to their regional DC).

All helpful replies are rated!

Kind regards, Ash.

Everyone's tags (2)

ISE v1.2 AuthC Policy Processing Performance


Authentication policies define the protocols that Cisco ISE should use to communicate with the network devices, and the identity sources that it should use for authentication. A policy is a set of conditions and a result. A policy condition consists of an operand (attribute), an operator (equal to, not equal to, greater than, and so on), and a value. Compound conditions are made up of one or more simple conditions that are connected by the AND or OR operator. At runtime, Cisco ISE evaluates the policy condition and then applies the result that you have defined based on whether the policy evaluation returns a true or a false value.

For more information regarding your case scenario and configuration, please go to this link (page no 429-440):

Cisco Employee

ISE v1.2 AuthC Policy Processing Performance

ISE profiling and Guest Services, can cause lots of database replication traffic due to their frequent database writes and updates. As a result, lower latency and higher bandwidth WAN links are necessary when using these services within your ISE deployment.Use "ISE bandwidth and latency calulator ". You can use ISE Alarms how you want to be notified about system activities .following link lists all the Cisco ISE alarms, descriptions and their resolution


ISE v1.2 AuthC Policy Processing Performance

Kindly find the link below may help you have some information and address your query.

Filtering Endpoint Attributes

Cisco ISE, when enabled with multiple probes per node, experiences a considerable performance degrading due to numerous attributes per endpoint are collected and stored in the administration node database. Some of the attributes that are collected are temporal in nature as well as not required for endpoint profiling. The huge collection of attributes per probe for each of the endpoint, which cannot be used for endpoint profiling, result in Cisco ISE administration node database persistence and performance degrading.

To address performance degrading of Cisco ISE, filters for RADIUS, DHCP for both the DHCP Helper and DHCP SPAN, HTTP, and SNMP probes have been implemented in the profiler probes (except for the NetFlow probe). Each probe filter contains the list of attributes that are temporal and irrelevant for endpoint profiling and removes those attributes from the attributes collected by the probes.