IP Phones not being profiled

[GRANT3779]

How does the profiler actually work behind the scenes for IP Phones as an example?

I configured two switches a few weeks back with all the relevant dot1x config and could see that the phones connected to these two switches were showing up in the "Cisco IP Phones Profile" so ISE has seen them.

I configured another 3 switches yesterday with the same config but at the moment no new phones have appeared in my "profiled phones" list.

Is there a timer or sorts or should the profiling just happen if there are phones connected to the switch.

I have the following config -

aaa server radius dynamic-author
client 2.2.2.2 server-key xxxx
client 3.3.3.3 server-key xxxx
auth-type all

ip radius source-interface Vlan500
radius-server attribute 6 on-for-login-auth
radius-server attribute 6 support-multiple
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 mac format ietf upper-case
radius-server attribute 31 send nas-port-detail
radius-server dead-criteria tries 3
radius-server deadtime 30

radius server RADIUS_ISE_1
address ipv4 2.2.2.2 auth-port 1812 acct-port 1813
key xxxx

radius server RADIUS_ISE_2
address ipv4 3.3.3.3 auth-port 1812 acct-port 1813
key xxxx

aaa group server radius ISE-GROUP
server name RADIUS_ISE_1
server name RADIUS_ISE_2

aaa authentication dot1x default group ISE-GROUP
aaa accounting dot1x default start-stop group ISE-GROUP
aaa authorization network default group ISE-GROUP
aaa authorization auth-proxy default group ISE-GROUP
aaa accounting update periodic 5
aaa accounting auth-proxy default start-stop group ISE-GROUP

dot1x system-auth-control

[agrissimanis]

ISE usually requires CDP or LLDP information from the switch to profile a phone correctly.

Do you use Device sensor or SNMP Query probe to get this information to ISE? I suspect there is a problem with profiling probe setup for these switches.

A scenario for profiling IP Phone would be something like this:

1 - Phone connects for the first time to the to the switch and switch sends RADIUS Access-Request
2 - ISE learns about the new endpoint from RADIUS Access-Request (Calling-Station-ID attribute)

If MAC address was all that ISE needs to profile the endpoint, at this point profiling would be completed.

If something more is needed, for example, CDP or LLDP data, the endpoint would be classed as Generic Cisco device for example (it knows that from the MAC address) and remain classed as that until it learns more about the endpoint.

3 - At this point, if switch received Access-Accept from ISE, switch would send Accounting-Request message to ISE.

3a. If device sensor feature is configured, switch would include CDP and other attributes in the Accounting-Request message, ISE would see these new attributes, update the endpoint, issue CoA and the endpoint would hit the correct profile next time, immediately afterwards. 

3b. If no device sensor is used, SNMP query probe could be configured. In this case ISE would initiate SNMP query to the switch, in response to RADIUS Accounting-Request for that particular endpoint. That query would request CDP cache data from the switch and several other bits of information. And again, when ISE receives that information it updates the endpoint, issues CoA, and phone ends up with the correct profile.

There is no specific delay with the profiling in ISE, it happens as quick as ISE can receive the information it needs and process it.

I skipped few details, profiling can get tricky, when these "advanced" attributes are used to make the profiling decision, but in summary, that is how it works.

You can go to Policies -> Profiling, find the model of your phone from the list and check exactly what checks ISE makes to profile the device.

Hope that helps, please Mark as correct, if this answers your question.