on - edited on by
thomas
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.
Profiling
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.
Vivek 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.
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?
