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.

[arane0001]

@Arne Bier  I have a question somewhat to profiling . I have profiled some endpoints using static identity group entries like Employee-IP-Phones but after a few days the endpoints keep going to its original identity group. I have purged rules set to not purge these endpoints but it still keeps happening even to other static Identity group. Why does it happen ?  is there a way to fix that ?

[Marcelo Morais]

Hi @arane0001 ,

 please double check if these Endpoints are not being purged in Operations > Reports > Reports > Audit > Endpoints Purge Activities.

Hope this helps !!!

[arane0001]

Yes, i have never purge rule set to not to purge the endpoints

[Arne Bier]

Are you talking about setting an endpoint to a static Endpoint Identity Group, or to a static Endpoint Profile? I have not seen ISE "re-profile" an endpoint that has been statically/manually set to a Endpoint Profile. That would be counter-productive. Likewise with endpoints that have a static Endpoint Identity Group assigned - ISE doesn't mess with those. 

Because the profiling logic can be quite intricate, and it happens asynchronously, one thing I would do is to give your custom Endpoint Profiles a high certainty factor - this ensures that your custom profile should always be selected over an existing Cisco provided profile, in the case where the certainty factors are identical (e.g. Cisco has 10 and you have 10 - it gets ambiguous). 

You need to check the endpoint lifespan to see if the badly haved ones are indeed new, or old endpoints. If they are new endpoints, then they must have been purged somehow.

What you see in Context Visibility is in fact a copy of the Oracle database (the source of truth) - Context Visibility is a separate database and it can sometimes get out of sync. I have occasionally had to Reset and Resync the Context Visibility (Cisco has a procedure on CCO for this)

[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