cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

1458
Views
16
Helpful
3
Replies
dtjacob
Beginner

Device sensors and profiling probes

I am the using the following device sensor configuration on the catalyst 3850 and 4500 models:

device-sensor filter-list sip list sip_profiling

tlv name device-name

tlv name device-version

tlv name device-vendor

!

device-sensor filter-list dhcp list dhcp_profiling

option name host-name

option name default-ip-ttl

option name requested-address

option name parameter-request-list

option name class-identifier

option name client-identifier

!        

device-sensor filter-list lldp list lldp_profiling

tlv name system-name

tlv name system-description

!        

device-sensor filter-list cdp list cdp_profiling

tlv name device-name

tlv name address-type

tlv name capabilities-type

tlv name platform-type

device-sensor filter-spec sip include list sip_profiling

device-sensor filter-spec dhcp include list dhcp_profiling

device-sensor filter-spec lldp include list lldp_profiling

device-sensor filter-spec cdp include list cdp_profiling

device-sensor accounting

device-sensor notify all-changes


I am trying to profile a Cisco IP Phone 7841.  The switchport is configured with a voice vlan and cdp is enabled.  ISE is configured with a wired MAB policy that uses an endpoint groups for voip phones AND cisco-ip-phone profiling to assign the ip phone to a voice vlan. When I had the following probes enabled on the PSNs - radius, dhcp, http, snmpquery, and snmptrap - the ip phone was correctly profiled and immediately assigned to the voice vlan.  When I configured the PSNs to only use radius for profiling, it took the phone a very long time to correctly profile and sometimes not they didn't authorize at all.  I figured out the issue was profiling.  My question is....even though device sensors are configured on the switch and passed to ISE via Radius, do I need to have the DHCP and Radius probes enabled to properly profile an IP phone?

1 ACCEPTED SOLUTION

Accepted Solutions
hslai
Cisco Employee

ISE RADIUS probe should be able to collect the CDP attributes for the phone, without enabling other probes. I would suggest to temporarily enable profiling DEBUG and check profiler.log or engage Cisco TAC to troubleshoot.

View solution in original post

3 REPLIES 3
hslai
Cisco Employee

ISE RADIUS probe should be able to collect the CDP attributes for the phone, without enabling other probes. I would suggest to temporarily enable profiling DEBUG and check profiler.log or engage Cisco TAC to troubleshoot.

View solution in original post

Please make sure to turn on Radius accounting. CDP information is sent via Radius accounting packets.

Cory Peterson
Contributor

I know I am a bit late to this one but also keep in mind that Device Sensor / Radius Accounting ONLY happens after a successful authentication. So if the phone is failing Auth for whatever reason then ISE will never receive any of the information from the switch through RADIUS.

This boils down to the way radius works and will not send account packets for any device that is failing Authorizations.

There was also a bug reported on this but it was closed stating that  it is only a documentation bug and this is working as intended.  Bug ID: CSCux48616

It would be nice to gather this information even on a failed Auth so that ISE can correctly profile the device and then send a COA to the device to apply the correct policy.

One work around would be to do an access accept at the bottom of the MAB policy with a very restrictive dACL or even a deny any any.

Content for Community-Ad