Showing results for 
Search instead for 
Did you mean: 

Chalk Talk: Tips and Tricks to Make an ISE Deployment Stable and Scalable


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 personas. 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  white-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 white 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 a 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?