Cisco ISE Profiling limitations

[austinkuklok35]

Hello everyone! 

Thought I would post here cause I have not been able to find an answer to this question anywhere. 

We are using a product called Medigate (now called Claroty XDome) to profile endpoints and IoT and are piping that information to ISE for use in access policies. 

How ever there is a banner withinn the XDome integration section that has me confused and from the people I talked to no one can say if it's true or not.

Above is the banner that is there, how ever there are already ~850 profiling policies pre configured within ISE. 

I also looked in ISE Profiling Design Guide - Cisco Community

Performance and Scalability Guide for Cisco Identity Services Engine - Cisco

and was not able to find anything about this limit. 

We are using primarily IoT Asset assetDeviceType attribute from xDome to assign SGTs in access policy, which has us under the thresh hold of 1000 but I manually had to create each of the profiling policies. I would like to import this XML to not have to manually create profiling policies down to the model in the cases that we need too. The XML would have roughly 1800 policies.

we have 2 psns currently running with room to add 1 more, each psn is under 10% load. We have roughly 25k devices authenticating daily. currently running ISE3.3 P4.

Are we fine to import this? is that limit arbitrary now?

Thanks!

[Arne Bier]

Such a great question - I wasn't aware of such a limit, and I am sure we would have heard about it. Unless Cisco has come up with some marvel of programming logic, that reduced the complexity order to something other than linear, then I would say it makes sense to keep the number of Profiles to a minimum. I also tend to de-tune the Cisco provided Logical Profiles, in the vain hope that it reduces the processing required (e.g. I don't have PlayStation in my network ... so get rid of that) - I am keen to hear that others know on this topic.

On a related note, I am starting to wonder also, if there is a negative impact to ISE's ability to process the Authorization Rules, where there are so many Profiling Policies in place. In particular, I use a lot of Logical Profiles, and in my Authorization Policies I use them in the Conditions. I noticed that in ISE 3.3p4 that the Policy Set will often not find the Endpoint Profile of an endpoint, even though it's 100% profiled. The end result, is that my AuthZ hits the last rule and the endpoint is not Authorized as expected.

e.g. Cisco 3800 WAP profiled as such, and is part of a logical profile. Sometimes it matches, sometimes it doesn't.  I discovered this when I set the session-timeout to 65535 to force endpoints to re-auth. And when I combined this with a "clear access-session" on a switch, it meant that every 18.1 hours, the switch would send an avalanche of requests to ISE - I say "avalanche" ... even if the switch only had 50 endpoints, around half of them would not get authorized correctly. If I cleared each session one-by-one, then I have no issues.  Therefore it's not a problem with profiling, because the endpoints are never re-profiled. It's an issue with processing the Authorization Policy Set under "load" ... and one TAC engineer mentioned to me the possibility of a mutual exclusion bug where they think that when parallel requests are being executed, something goes wrong. Very wrong indeed.

The PSNs are not loaded at all. I can clear a switch that has 500 endpoints, and if all of those endpoints are Authorized by a Rule in ISE that does NOT use profiling conditions, then I have no issues at all.

Moral of the story - something fishy is going on here and I am hoping the TAC will find it - I have reproduced this and given TAC debugs of working and non-working situation. 

[wags]

Arne, can you share the TAC case number for what you mention seeing? 

We seem to see this in our production environment.  We've found some performance improvements with our ISE configuration that have helped quite a bit, but still see some of it.   We also see what looks like an IOS-XE issue within the authenticator module/software which we have an open TAC case on.  Like you, if we work with the interfaces one by one things clear up.  Kind of impractical on a loaded C9410.

[PSM]

This pain looks familiar to us. We are also struggling with profiling issues. With same profiling policy few endpoints are being profiled correctly but others not. And number of profiled endpoints changes sometimes. We are running ISE 3.2 patch 7, which is different then yours @Arne Bier