Showing results for 
Search instead for 
Did you mean: 
Vivek Santuka
Cisco Employee
Cisco Employee


Deploying Identity Services Engine (ISE) can be a long process and certain decisions made early in the deployment can save a lot of frustration at a later stage. In this article, I look at some of the common problems that can prevent an ISE deployment from being scalable or stable. The intention is to provide tips and tricks that can be considered during the design or initial deployment phase to avoid problems at a later stage.

These tips are divided into 4 sections with each section dealing with different aspect of ISE deployment.


Initial Configuration

Tip 1: It is common to use temporary values for initial configuration with the intention to change it at a later stage. Unfortunately, ISE does not like changes of the basic configuration and a lot of these changes, such as time zones, require a complete reset of the configuration. Hence, it is essential to think the initial configuration through and avoid changing it later.


Tip 2: It is better to use a single DNS domain for all nodes in the deployment. ISE has its share of problems with split domain configuration and requires some work to get such a configuration working. If possible, use a single DNS domain.


Tip 3: All database passwords need to be common across the deployment. So ensure that you remember the database passwords set during the initial setup script or else you will not be able to add new nodes to the deployment.


Trick 1: If you forget the database password, you can change it from the ISE CLI using the application reset-passwd ise { internal-database-admin | internal-database-user } command.


Building the Deployment

Tip 1: The primary admin node is not an idle node that is used only for configuration changes. The primary admin node receives and distributes information from the policy nodes. The majority of this information is profiling information and in a sufficiently busy deployment, the admin node can be over-subscribed easily.


Tip 2: In a large network, consider using dedicated admin and monitoring nodes instead of a single node with both the personae. Monitoring and Admin nodes both have a high database read and write function and this can be taxing on the CPU.


Tip 3: Replication between ISE nodes can be almost continuous in deployments with lot of profiling. ISE is not very tolerant to replication problems and the impact of a replication problem can snowball fast, if not fixed. If nodes lie across slow or over-subscribed links, consider using QOS for ISE replication traffic.



Tip 1: Profiling is the most resource-intensive function of ISE and improper profiling configuration is one of the biggest reasons for an unstable deployment. Before enabling profiling, consider the actual need and the minimum required information for the desired profiling result. Based on this, enable only those probes that are needed to achieve that result.


Tip 2: Even though the policy nodes collect the profiling data, it is processed and recorded by the Admin node and Monitoring node. The admin node in turn replicates all profiling information immediately to all other nodes in the deployment. Excessive profiling can overwhelm the Admin and Monitoring nodes too, so it is important to have just the required profiling probes enabled.


Tip 3: Avoid duplicating profiling work by disabling probes that collect similar information. For example, both DHCP and DHCP SPAN probes should not be enabled at the same time.


Tip 4: If a large number of endpoints is being profiled, enable the profiling allow-list feature on ISE 1.1.2. When enabled, this feature creates a list of required attributes based on the profiling rules. Policy nodes drop any attribute that is not in the list. This reduces the amount of data that is collected and decreases resource usage.


Trick 2: The Profiling allow list or EndPoint Attribute Filter can be enabled at the Administration->System->Settings->Profiling page. This feature was introduced in ISE 1.1.2


Tip 5: If you have a large amount of RADIUS traffic, consider disabling the RADIUS profiling probe and using an alternative. This is especially true in very large wireless networks where hundreds of thousands of end points authenticate in a day.


Authentication and Authorization

Tip 1: When implementing ISE-based authentication in a large network, especially a large Wireless network, it is important to ensure that the clients are properly configured and end-users know the process for on-boarding or Guest authentication. Failure to do so can result in very high number of authentication failures hitting ISE repeatedly. This will result in resource exhaustion.


Tip 2: Ensure correct authentication failure or client exclusion configuration is in place on network devices to avoid misconfigured clients from initiating repeated authentication failures.


Trick 3: Authorization rules that use external group membership, as a condition should be put lower in order than those that do not check for them. This is suggested because if the external group-based authorization rules are on the top, all authentication attempts will trigger a search to the external database and hence increase resource usage and response time. For example, MAB requests do not require external group check, so authorization rules dealing with such requests should be on the top of the authorization rules page.


Tip 3: If periodic re-authentication is required, select the maximum time that you can for the re-authentication period. Excessive re-authentication can become a reason for high resource usage on ISE and create a resource contention situation. Re-authentication can also be triggered by port-security on switches. Avoid using port-security aging on 802.1x enabled interfaces.


While the above list is not exhaustive, it does include some of the most commonly seen problems with new ISE deployments. As is evident from the general trend of the tips, most problems with ISE occur due to resource exhaustion caused by mis-configuration and almost all of these can be avoided with careful planning.



vsantuka.jpgVivek Santuka is a Customer Support Engineer with Cisco TAC AAA team. In the last 7 years, Vivek has helped resolve thousands of AAA, ACS and NAC related cases for organizations of all sizes. He holds two CCIEs,one in Security and the other in Routing and Switching. In addition to that, he holds an RHCE certification. Vivek is also the co-author for the Cisco Press title AAA Identity Management Security.






AAA Identity Management

By Vivek Santuka, Premdeep Banga, Brandon J. Carroll.


Published by Cisco Press.

Series: Networking Technology: Security.

Published: Dec 16, 2010

Copyright 2011

ISBN-10: 1-58714-144-2

ISBN-13: 978-1-58714-144-7



This article was featured in the January issue of the Cisco TS Newsletter. Are you subscribed?


Dear Vivek, a great article. Have you found any methods/resources for automating the deployment of ISE? Similar to unattended installs of Windows OS deployments...whereby you provide answers in a file / database.

Vivek Santuka
Cisco Employee
Cisco Employee


It is possible to remotely connect to the Serial of a VM and "automate" the install and setup script but it would take a lot of scripting effort and would not be worth it for a deployment, however large.


Hello Vivek,

Very useful post!

Wouldn't you have some reference bandwidth values for QoS between MGM and PSN nodes? Assuming advanced license.

Thank you in advance!



Vivek Santuka
Cisco Employee
Cisco Employee

Hi Guido,

We do not have reference bandwidth values for QoS between ISE nodes. The only thing that ISE requires is for the RTT between nodes to be less than 200ms.




In practice, does ISE impact the remote administration of workstations (end points)? Can ISE block unauthorized servers from accessing an end point? I understand ISE protects the network from the end device, but can it also work in the reverse? Thank you!

Vivek Santuka
Cisco Employee
Cisco Employee


The answer is not really straight forward:

1. Before authentication : By default no traffic is allowed from or to the end host. You can change that to incoming only to allow servers to send a Wake on LAN packet. The port can have a default ACL to allow traffic from certain servers. Remember that ISE has no control over the endpoint at this time. All you have is static policies here.

2. Post-Authentication: By default this results in all traffic being allowed in both directions. You can choose to apply an ACL as a result of authentication, in either direction. In the ACL you can choose to allow or deny what you need.

Having said that, remember that the access port in NOT the place for filtering. While some filtering is fine, majority of filtering should be done upstream.


Hi Choi,

I can't access your lab.Please invite me, I really interest to study switching..This is my


prashant dwivedi

Hello Guys,

Can someone please help me with below ISE queries ?

1- ISE is in the production network, however now we are in the position to enable guest SSID hence for that we need to have public CA sign certificate installed on PSNs. I have 4 PSNs, 2 MNT and 2 admin nodes, I would like to know if its ok to install this certifcate just on PSNs and Admin nodes, I Can ask for a certificate having multiple san fields ( PSNs and admin portals urls ) . if I proceed with this one , will it cause any issues in communciation between different nodes spically between MNT and other nodes as MNT is having different certs.

2- Any one has deployed ISE as a radius proxy ?

Thanks for help.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers
Quick Links