Contents
Introduction
Prerequisites
Requirements
Components Used
Configure
Step 1. Standard AAA configuration
Step 2. Configure Device Sensor
Step 3. Configure profiling on ISE
Verify
Troubleshoot
Step 1. Verify information collected by CDP/LLDP
Step 2. Check Device Sensor cache
Step 3. Check if attributes are present in Radius Accounting
Step 4. Verify profiler debugs on ISE
Related Information
Related Cisco Support Community Discussions
Introduction
This document describes how to configure Device Sensor, so that it can be used for profiling
purposes on ISE. Device sensor is a feature of access devices. It allows to collect information
about connected endpoints. Mostly, information collected by Device Sensor can come from the
following protocols:
● Cisco Discovery Protocol (CDP)
● Link Layer Discovery Protocol (LLDP)
● Dynamic Host Configuration Protocol (DHCP)
On some platforms it is possible to use also H323, SIP (Session Initiation Protocol),
MDNS (Multicast Domain Resolution) or HTTP protocols. Configuration possibilities
for device sensor capabilities can vary from protocol to protocol. As an example
above is available on Cisco Catalyst 3850 with software 03.07.02.E.
Once the information is collected, it can be encapsulated in radius accounting and send to a
profiling server. In this article Identity Service Engine (ISE) is used as a profiling server.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
● Radius protocol
● CDP, LLDP and DHCP protocols
● Cisco Identity Service Engine
● Cisco Catalyst Switch 2960
Components Used
The information in this document is based on these software and hardware versions:
● Cisco Identity Service Engine version 1.3 patch 3
● Cisco Catalyst Switch 2960s version 15.2(2a)E1
● Cisco IP Phone 8941 version SCCP 9-3-4-17
Configure
Step 1. Standard AAA configuration
In order to configure Authentication, Authorization and Accounting (AAA), follow the steps below:
1. Enable AAA using aaa new-model command and enable 802.1X globally on the switch
2. Configure Radius server and enable dynamic authorization (Change of Authorization - CoA)
3. Enable CDP and LLDP protocols
4. Add switchport authentication configuration
In newer software version command radius-server vsa send accounting is
enabled by default. If you cannot see attributes send in accounting, verify if the
command in enabled.
Step 2. Configure Device Sensor
1. Determine which attributes from CDP/LLDP are needed to profile the device. In case of Cisco IP
Phone 8941 you can use the following:
● LLDP SystemDescription attribute
● CDP CachePlatform attribute
For our purpose it would be enough to obtain just one of those since both of them provide
Certainty Factory increase of 70 and Minimum Certainty Factory required to be profiled as Cisco-
IP-Phone-8941 is 70:
In order to be profiled as specific Cisco IP Phone, youneed to satisfy minimum
conditions for all parent profiles. This means profiler needs to match Cisco-Device
(min. Certainty Factor 10) and Cisco-IP-Phone (min. Certainty Factor 20). Even though
profiler matches those two profiles, it should still be profiled as specific Cisco IP
Phone since each IP Phone model has min. Certainty Factor of 70. Device is assigned
to the profile for which it has highest Certainty Factor.
2. Configure two filter lists - one for CDP and another one for LLDP. Those indicate which
attributes should be included in Radius accounting messages. This step is optional
3. Create two filter-specs for CDP and LLDP. In fiter spec you can either indicate that list of
attributes should be included or excluded from accounting messages. In the example following
attributes are included:
● device-name from CDP
● system-description from LLDP
You can configure additional attributes to be transmited via Radius to ISE if needed. This step is
also optional.
4. Add command device-sensor notify all-changes. It triggers updates whenever TLVs
are added, modified or removed for current session
5. In order to actually send the information gathered via Device Sensor functionality, you need to
explicitly tell the switch to do so with command device-sensor accounting
Step 3. Configure profiling on ISE
1. Add switch as a network device in "Administration>Network Resources>Network Devices". Use
the radius server key from the switch as shared secret in Authentication Settings:
2. Enable Radius probe on the profiling node in "Administration>System>Deployment>ISE
node>Profiling Configuration". If all PSN nodes should be used for profiling, enable the probe on
all of them:
3. Configure ISE Authentication Rules. In the example the default authentication rules
preconfigured on ISE are used:
4. Configure ISE Authorization Rules. 'Profiled Cisco IP Phones' rule is used, which is
preconfigured on ISE:
Verify
In order to verify if profiling is working correctly, please refer to "Operations>Authentications" on
ISE:
First the device was authenticated using MAB (18:49:00). Ten seconds later (18:49:10) it was
reprofiled as Cisco-Device and finaly after 42 seconds since first authentications (18:49:42) it
received Cisco-IP-Phone-8941 profile. As a result ISE returns Authorization Profile specific for IP
Phones (Cisco_IP_Phones) and Downloadable ACL that permits all traffic (permit ip any any).
Please note that in this scenario the unknown device has basic access to the network. It can be
achieved by adding mac address to ISE internal endpoint database or allowing very basic network
access for previously unknown devices.
Initial profiling took around 40 seconds in this example. On the next authentication
ISE already knows the profile and correct attributes (permission to join voice domain
and DACL) are applied instantly, unless ISE receives new/updated attributes and it
needs to reprofile the device again.
In "Administration>Identity Management>Identities>Endpoints>tested endpoint" you can see what
kind of attributes were collected by Radius probe and what their values are:
As you can observe the total Certainty Factor computed is 210 in this scenario. It comes fromt the
fact that endpoint matched also Cisco-Device profile (with total certainty factor of 30) and Cisco-
IP-Phone profile (with total certainty factor of 40). Since profiler matched both conditions in profile
Cisco-IP-Phone-8941, certainty factor for this profile is 140 (70 for each attribute according to
profiling policy). To sum up: 30+40+70+70=210.
Troubleshoot
Step 1. Verify information collected by CDP/LLDP
If you cannot see any data collected verify the following:
● Check the state of authentication session on the switch (it should be successful):
● Check if CDP and LLDP protocols are enabled. Check if there are any non-default commands
regarding CDP/LLDP/etc. and how those can affect attribute retrieval from the endpoint
● Verify in configuration guide for your endpoint if it supports CDP/LLDP/etc
Step 2. Check Device Sensor cache
If you do not see any data in this field or information is not complete verify 'device-sensor'
commands, in particular filter-lists and filter-specs.
Step 3. Check if attributes are present in Radius Accounting
You can verify that using 'debug radius' command on the switch or performing packet capture
between switch and ISE.
Radius debug:
Mar 30 05:34:58.716: RADIUS(00000000): Send Accounting-Request to 1.1.1.1:1813 id 1646/85, len
378
Mar 30 05:34:58.716: RADIUS: authenticator 17 DA 12 8B 17 96 E2 0F - 5D 3D EC 79 3C ED 69 20
Mar 30 05:34:58.716: RADIUS: Vendor, Cisco [26] 40
Mar 30 05:34:58.716: RADIUS: Cisco AVpair [1] 34 "cdp-tlv= "
Mar 30 05:34:58.716: RADIUS: Vendor, Cisco [26] 23
Mar 30 05:34:58.716: RADIUS: Cisco AVpair [1] 17 "cdp-tlv= "
Mar 30 05:34:58.721: RADIUS: Vendor, Cisco [26] 59
Mar 30 05:34:58.721: RADIUS: Cisco AVpair [1] 53 "lldp-tlv=
"
Mar 30 05:34:58.721: RADIUS: User-Name [1] 19 "20-BB-C0-DE-06-AE"
Mar 30 05:34:58.721: RADIUS: Vendor, Cisco [26] 49
Mar 30 05:34:58.721: RADIUS: Cisco AVpair [1] 43 "audit-session-
id=0AE518200000022800E2481C"
Mar 30 05:34:58.721: RADIUS: Vendor, Cisco [26] 19
Mar 30 05:34:58.721: RADIUS: Cisco AVpair [1] 13 "vlan-id=101"
Mar 30 05:34:58.721: RADIUS: Vendor, Cisco [26] 18
Mar 30 05:34:58.721: RADIUS: Cisco AVpair [1] 12 "method=mab"
Mar 30 05:34:58.721: RADIUS: Called-Station-Id [30] 19 "F0-29-29-49-67-0D"
Mar 30 05:34:58.721: RADIUS: Calling-Station-Id [31] 19 "20-BB-C0-DE-06-AE"
Mar 30 05:34:58.721: RADIUS: NAS-IP-Address [4] 6 10.229.20.43
Mar 30 05:34:58.721: RADIUS: NAS-Port [5] 6 60000
Mar 30 05:34:58.721: RADIUS: NAS-Port-Id [87] 23 "GigabitEthernet1/0/13"
Mar 30 05:34:58.721: RADIUS: NAS-Port-Type [61] 6 Ethernet [15]
Mar 30 05:34:58.721: RADIUS: Acct-Session-Id [44] 10 "00000018"
Mar 30 05:34:58.721: RADIUS: Acct-Status-Type [40] 6 Watchdog [3]
Mar 30 05:34:58.721: RADIUS: Event-Timestamp [55] 6 1301463298
Mar 30 05:34:58.721: RADIUS: Acct-Input-Octets [42] 6 538044
Mar 30 05:34:58.721: RADIUS: Acct-Output-Octets [43] 6 3201914
Mar 30 05:34:58.721: RADIUS: Acct-Input-Packets [47] 6 1686
Mar 30 05:34:58.721: RADIUS: Acct-Output-Packets [48] 6 35354
Mar 30 05:34:58.721: RADIUS: Acct-Delay-Time [41] 6 0
Mar 30 05:34:58.721: RADIUS(00000000): Sending a IPv4 Radius Packet
Mar 30 05:34:58.721: RADIUS(00000000): Started 5 sec timeout
Mar 30 05:34:58.737: RADIUS: Received from id 1646/85 10.62.145.51:1813, Accounting-response,
len 20
Packet capture:
Step 4. Verify profiler debugs on ISE
If the attributes were sent from the switch, it is possible to check if they were received on ISE. In
order to check this, please enable profiler debugs for correct PSN node
(Administration>System>Logging>Debug Log Configuration>PSN>profiler>debug) and perform
authentication of the endpoint one more time.
Look for following information:
● Debug indicating that radius probe received attributes:
2015-11-25 19:29:53,641 DEBUG [RADIUSParser-1-thread-1][]
cisco.profiler.probes.radius.RadiusParser -:::-
MSG_CODE=[3002], VALID=[true], PRRT_TIMESTAMP=[2015-11-25 19:29:53.637 +00:00],
ATTRS=[Device IP Address=10.229.20.43, RequestLatency=7,
NetworkDeviceName=deskswitch, User-Name=20-BB-C0-DE-06-AE,
NAS-IP-Address=10.229.20.43, NAS-Port=60000, Called-Station-ID=F0-29-29-49-67-0D,
Calling-Station-ID=20-BB-C0-DE-06-AE, Acct-Status-Type=Interim-Update,
Acct-Delay-Time=0, Acct-Input-Octets=362529, Acct-Output-Octets=2871426,
Acct-Session-Id=00000016, Acct-Input-Packets=1138, Acct-Output-Packets=32272,
Event-Timestamp=1301458555, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/13,
cisco-av-pair=cdp-tlv=cdpCachePlatform=Cisco IP Phone 8941 ,
cisco-av-pair=cdp-tlv=cdpUndefined28=00:02:00,
cisco-av-pair=lldp-tlv=lldpSystemDescription=Cisco IP Phone 8941\, V3\, SCCP 9-3-4-17,
cisco-av-pair=audit-session-id=0AE51820000002040099C216, cisco-av-pair=vlan-id=101,
cisco-av-pair=method=mab, AcsSessionID=ise13/235487054/2511, SelectedAccessService=Default
Network Access,
Step=11004, Step=11017, Step=15049, Step=15008, Step=15004, Step=11005,
NetworkDeviceGroups=Location#All Locations,
NetworkDeviceGroups=Device Type#All Device Types, Service-Type=Call Check,
CPMSessionID=0AE51820000002040099C216,
AllowedProtocolMatchedRule=MAB, Location=Location#All Locations, Device Type=Device Type#All
Device Types, ]
● Debug indicating that attributes were successfully parsed:
2015-11-25 19:29:53,641 DEBUG [RADIUSParser-1-thread-1][]
cisco.profiler.probes.radius.RadiusParser -:::-
MSG_CODE=[3002], VALID=[true], PRRT_TIMESTAMP=[2015-11-25 19:29:53.637 +00:00],
ATTRS=[Device IP Address=10.229.20.43, RequestLatency=7,
NetworkDeviceName=deskswitch, User-Name=20-BB-C0-DE-06-AE,
NAS-IP-Address=10.229.20.43, NAS-Port=60000, Called-Station-ID=F0-29-29-49-67-0D,
Calling-Station-ID=20-BB-C0-DE-06-AE, Acct-Status-Type=Interim-Update,
Acct-Delay-Time=0, Acct-Input-Octets=362529, Acct-Output-Octets=2871426,
Acct-Session-Id=00000016, Acct-Input-Packets=1138, Acct-Output-Packets=32272,
Event-Timestamp=1301458555, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/13,
cisco-av-pair=cdp-tlv=cdpCachePlatform=Cisco IP Phone 8941 ,
cisco-av-pair=cdp-tlv=cdpUndefined28=00:02:00,
cisco-av-pair=lldp-tlv=lldpSystemDescription=Cisco IP Phone 8941\, V3\, SCCP 9-3-4-17,
cisco-av-pair=audit-session-id=0AE51820000002040099C216, cisco-av-pair=vlan-id=101,
cisco-av-pair=method=mab, AcsSessionID=ise13/235487054/2511, SelectedAccessService=Default
Network Access,
Step=11004, Step=11017, Step=15049, Step=15008, Step=15004, Step=11005,
NetworkDeviceGroups=Location#All Locations,
NetworkDeviceGroups=Device Type#All Device Types, Service-Type=Call Check,
CPMSessionID=0AE51820000002040099C216,
AllowedProtocolMatchedRule=MAB, Location=Location#All Locations, Device Type=Device Type#All
Device Types, ]
● Debug indicating that attributes are processed by forwarder:
2015-11-25 19:29:53,643 DEBUG [forwarder-6][]
cisco.profiler.infrastructure.probemgr.Forwarder -:20:BB:C0:DE:06:AE:ProfilerCollection:-
Endpoint Attributes:
ID:null
Name:null
MAC: 20:BB:C0:DE:06:AE
Attribute:AAA-Server value:ise13
(... more attributes ...)
Attribute:User-Name value:20-BB-C0-DE-06-AE
Attribute:cdpCachePlatform value:Cisco IP Phone 8941
Attribute:cdpUndefined28 value:00:02:00
Attribute:lldpSystemDescription value:Cisco IP Phone 8941, V3, SCCP 9-3-4-17
Attribute:SkipProfiling value:false
A forwarder stores endpoints into the Cisco ISE database along with their attributes
data, and then notifies the analyzer of new endpoints detected on your network. The
analyzer classifies endpoints to the endpoint identity groups and stores endpoints
with the matched profiles in the database.
Step 5. Typically after new attributes are added to the existing collection for specific device, this
device/endpoint is added to profiling queue in order to check if it has to be assigned different
profile based on new attributes:
2015-11-25 19:29:53,646 DEBUG [EndpointHandlerWorker-6-31-thread-1][]
cisco.profiler.infrastructure.profiling.ProfilerManager -:20:BB:C0:DE:06:AE:Profiling:-
Classify hierarchy 20:BB:C0:DE:06:AE
2015-11-25 19:29:53,656 DEBUG [EndpointHandlerWorker-6-31-thread-1][]
cisco.profiler.infrastructure.profiling.ProfilerManager -:20:BB:C0:DE:06:AE:Profiling:-
Policy Cisco-Device matched 20:BB:C0:DE:06:AE (certainty 30)
2015-11-25 19:29:53,659 DEBUG [EndpointHandlerWorker-6-31-thread-1][]
cisco.profiler.infrastructure.profiling.ProfilerManager -:20:BB:C0:DE:06:AE:Profiling:-
Policy Cisco-IP-Phone matched 20:BB:C0:DE:06:AE (certainty 40)
2015-11-25 19:29:53,663 DEBUG [EndpointHandlerWorker-6-31-thread-1][]
cisco.profiler.infrastructure.profiling.ProfilerManager -:20:BB:C0:DE:06:AE:Profiling:-
Policy Cisco-IP-Phone-8941 matched 20:BB:C0:DE:06:AE (certainty 140)
2015-11-25 19:29:53,663 DEBUG [EndpointHandlerWorker-6-31-thread-1][]
cisco.profiler.infrastructure.profiling.ProfilerManager -:20:BB:C0:DE:06:AE:Profiling:-
After analyzing policy hierarchy: Endpoint: 20:BB:C0:DE:06:AE EndpointPolicy:Cisco-IP-Phone-8941
for:210 ExceptionRuleMatched:false
Related Information
1. http://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/design-zone-
security/howto_30_ise_profiling.pdf
2. http://www.cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_prof_pol.html
