ISE Profiling Logic - Need confirmation

[junk1]

Hi

It would be great if someone could please confirm the logic of ISE profiling.

My customer runs ISE 2.3 Patch 2.

DHCP helper address is enabled for Voice VLANs and Device Sensor (only included DHCP protocol, excluded cdp/lldp) is enabled on switches (Cat 45XX and Cat 3560).

When I connect a Cisco IP Phone 7811, ISE profiles it properly and the Total Certainty Factor value was 130. When I spoof the MAC address of this Phone in a laptop and connect, ISE calculates the TCF as 30 after detecting the DHCP parameters via Device Sensor RADIUS accounting packet. But the behaviour of ISE reprofiles the endpoint as Microsoft-Workstation from Cisco IP Phone 7811 is not consistent. Sometimes it does reprofiles, but sometimes it's still profiling the endpoint as Cisco IP Phone 7811.

Please confirm what will be the behaviour of ISE when it finds an endpoint profiled with lesser TCF than the previously calculated TCF - will it reprofiles?

This inconsistency is not observed when DHCP IP Helper address is enabled for both Voice and DATA VLANs. Is this an expected behaviour of Device Sensor shared information to ISE?

When I have a Cisco provided Endpoint Policy for Cisco IP Phone 7811, and when I Duplicate the same as Cisco IP Phone 7811-ABC (Administrator Created), which will the endpoint hit when connected and what is the logic? I see the Administrator created is hitting instead of Cisco provided. Any priority behind this?

Please suggest the general behaviour of ISE Profiling logic.

Thanks in advance,

V Vinodh.

[ldanny]

Any reason you are using dhcp helper as well as device-sensor for DHCP?

I would recommend using one or the other and not both to see if result is consistent.

See the following design guide explaining profiling

How To: ISE Profiling Design Guide

[Craig Hyps · Accepted solution]

Vinodh,

I appreciate the fact that you are leveraging the Community, but since this involves a case we have been working on, let's continue to address offline.

If have the endpoint details before and after re-profile, then it is typically a simple matter to deduce the reasons for profile change.  Even if have just the final endpoint details, the current profile assignment can be deduced.  There is also the profile change summary report which can aid in learning the changes effecting change.

As Danny cited, the proposal for your customer was to do one or the other, not both.  Device Sensor is the generally preferred method for data collection due to its ability to collect multiple attributes locally from source and package them into a single probe via RADIUS Accounting.  For cases where Sensor is not available, the traditional methods like IP Helper relay and SNMP Query can be used.

As cited earlier offline, there is a known issue that could impact customer
CSCvg46278 - ISE 2.3 Profiler anomalous endpoint detection with DHCP probe and Device Sensor

This could result in improper classification or even trigger Anomalous Endpoint. However, it was stated that Device Sensor was working as expected, so suggest to continue down that path and avoid case of double collection via two methods.  If Device Sensor is not providing the same result as ip helper, then very well may be hitting CSCvg46278.

Just based on your description, I will tell you exactly what is happening:

     Cisco Phone OUI with DHCP Class ID = Cisco Systems, Inc IP Phone CP-7811

          Matches OUI and rule (CF=10) and DHCP Class rule (CF=10) at top level

          Matches two DHCP Class rules based on Cisco/IP Phone for CF=20 each at IP Phone child level

          Matched DHCP Class at 7811 profile with CF=70.

          TCF = 10 + 10 + 20 + 20 + 70 = 130

Now a simple change in the DHCP Class to MSFT strips away all the CF from above to only 10 and it now matches the Microsoft Workstation policy where...

     Cisco Phone OUI with DHCP Class ID = MSFT 5.0

          Matches DHCP Class rule (CF=20) at parent Workstation profile

          Matches same DHCP Class rule (CF=10) at Microsoft WS child level

          TCF = 20 + 10

If make duplicate profiles with same rules and weighting, then profile selection will be non-deterministic.  There is no tie-breaker logic today.