Can LSD/LDD be grouped to select PSNs only? More Profiler questions

[Arne Bier]

Hello,

I am still wrapping my head around ISE LSD/LDD (Lightweight Session Directory/Lightweight Data Directory) - which I believe is made up of two further acronyms RSD (RADIUS Session Directory) and EPOD (Endpoint Owner Directory).  I have read docs explaining what the feature does but I can't understand why this is even exposed to the end-user. If it's such a beneficial feature as the docs say, then why is it optional? It's also on by default. What is the use-case of having to disable this?

I have another question relating to Node Groups and LDD in general. Node Groups made sense to me because I could take a bunch of PSNs of interest and put them into a group so that I had some kind of session failover mechanism (PSN1 dies, and PSN2 sends CoA to recover the session etc.) - the reason I like Node Groups is that I can include only the PSNs that matter to me. In a large ISE deployment I might have two PSNs for TACACS only, two PSNs for wireless processing only, and two PSN's for wired processing. At this point I don't want to replicate session data across all 6 PSNs because a wireless session doesn't need to replicate to a TACACS node, nor to a PSN handling wired sessions. How do I tell LDD that I don't want endpoint ownership replicated to all PSNs? Also, I might have PSNs distributed over large geographies and I want to avoid all this replication to happen over a (slow) WAN.

Anyone got any ideas about when to change the Batch and TTL settings under LDD > Advanced ?

I would also love to know whether the Profiler Setting "Enable Profiler Forwarder Persistence Queue" should be enabled or not.

And is it safe to simply enable the "EndPoint Attribute Filter" too? Why is this not an obvious setting (set to on)?

I feel like these things are all related, but I would recommend some real world feedback with how best to use them all in combination in large PSN deployments where profiling is used. No posture or guest is used. 

[Marcelo Morais]

Hi @Arne Bier ,

1st LSD/LDD

 Since 2.7 P3 the Endpoint Ownership information (Endpoint Ownership Enhancement) is stored across ALL the PSNs with the help of the LSD - renamed to LDD RADIUS Session Directory (introduced in ISE 2.6 - Administration > System > Settings > Light Data Distribution). This avoids Endpoint Ownership flapping !!!

 With LDD every PSN can find an actual owner of the Session from the local RADIUS Session Directory cache.

 LDD is used to store User Session Information and replicate it across the PSNs in a Deployment, thereby eliminating the need to be dependent on the PAN or MnT Nodes for User Session details. In case of connectivity issues between the PSNs, for example, when a PSN is down, the Session Details are retrieved from the MnT Session Directory and stored for future use.

LDD uses Cisco ISE Messaging Services for inter-node communication, because of that, disabling the ISE Internal CA is not recommended.

2nd RADIUS Session Directory

 The RADIUS Session Directory is used to store the User Session Information and replicate it across the PSNs in a Deployment. This directory stores ONLY the Session Attributes that are required for CoA.

 This functionality is enabled by default from ISE 2.7.

3rd Endpoint Owner Directory
 Until ISE 2.6, when an Endpoint Probe is received on a PSN (that is different from the one that originally handled the requests for that specific Endpoint), the Endpoint Owner is changed to the new PSN. This results in Endpoint Ownership flapping (Change of Ownership).

From ISE 2.7, the Endpoint Owner Directory is used to store the PSN FQDN of each MAC Addr connecting to ISE and to replicate this data across the PSNs in a Deployment. This avoids Endpoint Ownership flapping because ALL the PSNs are now aware of all the Endpoint Owners. The Endpoint Ownership now changes ONLY in case of a successful RADIUS Authentication of that Endpoint on another PSN.

In addition, the static Endpoint assignments are prioritized over the attributes received by an incoming Probe for the same Endpoint, avoiding attribute override issues.

This feature is enabled by default from ISE 2.7.

4th Enable Profiler Forwarder Persistence Queue
 Enabled by default. Helps to prevent data loss. You can disable this feature to fall back to the original mechanism, where events are sent directly to the Profiler module.

5th EndPoint Attribute Filter

Aka Whitelist Filter, best practice in Large Deployments to reduce Global Replication.

NOTE: approximately every 12hrs, PSNs sync Endpoint Attributes with PPAN.

Hope this helps !!!

[Marcelo Morais]

Hi @Arne Bier ,

 sorry ... I forgot to add the last  question ...

6th Advanced Settings

Note: the following numbers are "magical numbers" for me : ) ...  but let's talk about the meaning !!!

Batch Size
The Session Updates can be sent in batches. This value specifies the number of records sent in each batch from a LDD instance to the other PSNs in the Deployment. If this field is set to 1, the Session Updates are NOT sent in batches. The default value is 10 records.
TTL
This value specifies the maximum time a Session will wait for a batch to complete before updating the LDD. The default value is 1000 ms.

Hope this helps !!!

[Arne Bier]

thanks @Marcelo Morais - I have read all this stuff in the documentation but it doesn't explain when NOT to use something. in other words, is there a legitimate reason to NOT use these fancy features? 

Also, it's not a very granular mechanism - I assume that every PSN that has Session Services enabled will get this data, whether or not it will ever need it. That's the part that bothers me - especially if one has grouped various PSNs for different tasks (wired, wireless, guest).

I think I have also sort of understood the reason for the option to enable/disable Endpoint Attribute Filter - again, sounds like a no-brainer to enable this always. But the Profiling Guide says that you should disable it while "discovering endpoint attributes" in the early stages of deployment for "visibility reasons" only.  The excellent 3699 session below seems to indicate that it's ok to enable the attribute filter - not sure what they mean by "other attributes" ? In the case where we use Cisco-Provided rules and also Admin created rules, we should be ok to enable this?  

[Marcelo Morais]

Hi @Arne Bier ,

 for EndPoint Attribute Filter:

It's recommended to enabled it at the end of the deployment to reduce Global Replication.  Profiler only keep Significant Attributes and discard all the others.

Remember that replication to PAN occurs if Significant Attributes changes, then sync ALL attributes via PAN. if Whitelist Filter enabled, ONLY Whitelist Attributes synced to ALL Nodes.

 for " ... it doesn't explain when NOT to use something... "

 I use the LDD feature to avoids/minimize Endpoint Ownership flapping. (I have a lot of Profiler problems caused by a Load Balancer with "persistence issues")

 I use the Enable Profiler Forwarder Persistence Queue to prevent data loss ... but this feature I already tested "uncheck" (without issues), just to make the process faster since the info was sent directly to the Profiler Module and not to a Queue.

Note: I already unchecked ALL these 2.7 new feature in a 300K+ Deployment during a 2.4 >> 2.7 migration, without issues, just to verify the new features of 2.7 step by step (I enabled each one at different time)

Regards

[Marcelo Morais]

Hi @Arne Bier ,

 please take a look at the following at BRKSEC-3699:

Regards

[Arne Bier]

yeah I have seen all this before - but I don't understand it.

I just did a comparison between attribute filter disabled, and enabled - using a Windows 10 PC authenticating with EAP-PEAP and object exists in AD. When filter is disabled, I see loads of data like the TLS version used, and a lot of data about the object in AD. But as soon as I enable the filter, I no longer see the TLS version and the AD object information. These are just some of the differences. My question is: what is the impact of NOT having these attributes visible in Context Visibility? Is the data still stored in PAN somewhere, but just not replicated to all the PSNs, or is the data simply never collected at all?

I understand the fact that we don't need to keep or replicate endpoint attributes that we don't use in our Policy Set logic, or in our Profiler logic. I guess I want to be 100% sure that Profiler Logic will keep working when I enable this filter. I have custom profiler conditions in use. From what I read, ISE is smart enough to not prune those attributes that are used in custom profiler conditions.

Hence ... back to my original question - why isn't this enabled by default?  If anything, there should be an option to explicitly REVEAL ALL attributes feature that users can enable if they are curious about what ISE COULD collect if so required. But in most cases if Cisco profiler conditions are in use, and some admin created profiler conditions, then the filter should be on by default. 

Stated differently, the option we know as Endpoint Attribute Filter=disabled, should be called the "Endpoint Attribute Curiosity" feature ... for those who are curious about their endpoints - because it shows attributes that nobody can use in profiling conditions anyway - so it's a waste of time to collect and purely for curiosity/debugging purposes - right?

[Marcelo Morais]

Hi @Arne Bier ,

 " ... why isn't this enabled by default?   ... " in my humble opinion, the Endpoint Attribute Filter is not enabled by default because it is "best used" in Large Deployments only.

 " ...  Is the data still stored in PAN somewhere ... ", my understanding is ... replication to PAN occurs only if Significant Attribute changes. If White List Attributes changes, then replication occurs only between PSN (over Local Cluster Channel)

 " ... for those who are curious about their endpoints ... ", you have a point here !!! I'm in this group of curious people, but at the same time I'm trying to change the fact that " ... nobody can use ...". For ex.: at Context Visibility > Endpoints > click the Cog Wheel > Create New > select Attribute Categories = All Attributes (88) ... only 88 ... unfortunately the  InactiveDays and ElapseDays attributes are missing (for me they are important because of ISE: possibility to add InactiveDays and ElapseDays as Columns of the Context Visibility).

Regards