Using LLDP to profile a device based on system name

SMD28316 · ‎07-04-2021

I want to profile a non cisco IP phone (that uses MAB) by LLDP System name with ISE, from the packet captures on ISE TCP Dump, I can see that the System Name is being sent in the accounting request packet (Model name is SSP2210SLT):

But I don't see any LLDP-TLV in the access-request packet.

LLDP seems to be working correctly for the interface:

SW#sh lldp neigh gi0/3 det
------------------------------------------------
Local Intf: Gi0/3
...
Port Description: eth0
System Name: SSP2210SLT
...

My question is how am I supposed to profile the device based on LLDP attributes if I can't send them via access-request packets?

Below is my AAA/LLDP config, am I missing something?

aaa new-model
!
!
aaa group server radius dnac-client-radius-group
 server name dnac-radius_<First IP>
 server name dnac-radius_<Sec IP>
 ip radius source-interface Vlan1047
!
!
aaa authentication dot1x default group dnac-client-radius-group
aaa authorization exec default local 
aaa authorization network default group dnac-client-radius-group 
aaa accounting update newinfo periodic 2880
aaa accounting identity default start-stop group dnac-client-radius-group
!
!
!
!
!
aaa server radius dynamic-author
 client <First IP> server-key 7 <removed>
 client <Sec IP> server-key 7 <removed>
!
device-sensor filter-list lldp list iseLLDP
 tlv name system-name
 tlv name system-description
 tlv name system-capabilities
!
device-sensor filter-list dhcp list iseDHCP
 option name host-name
 option name parameter-request-list
 option name class-identifier
!
device-sensor filter-list cdp list iseCDP
 tlv name device-name
 tlv name capabilities-type
 tlv name version-type
 tlv name platform-type
device-sensor filter-spec dhcp include list iseDHCP
device-sensor filter-spec lldp include list iseLLDP
device-sensor filter-spec cdp include list iseCDP
device-sensor notify all-changes
!
ip device tracking probe auto-source override
ip device tracking probe delay 60
!
!
access-session attributes filter-list list Def_Acct_List
 cdp
 lldp
 dhcp
 http
!
!
dot1x system-auth-control
dot1x critical eapol
!
!
lldp run
!
!
interface GigabitEthernet0/3
 switchport mode access
 ip device tracking maximum 10
 switchport voice vlan 2046
 mab
 access-session control-direction in
 access-session closed
 access-session port-control auto
 authentication periodic
 authentication timer reauthenticate server
 spanning-tree portfast edge
  service-policy type control subscriber PD_MAB
!
!
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 mac-only
radius-server dead-criteria time 5 tries 3
radius-server deadtime 3
!
radius server dnac-radius_<First IP>
 address ipv4 First IP auth-port 1812 acct-port 1813
 timeout 4
 retransmit 3
 key 7 <removed>
!
radius server dnac-radius_<Sec IP>
 address ipv4 Sec IP auth-port 1812 acct-port 1813
 timeout 4
 retransmit 3
 key 7 <removed>
!

Marcelo Morais · ‎07-04-2021

Hi @SMD28316 ,

please check the TLV using the:

switch#show device-sensor cache interface g0/3

Note: in ISE, you can see the TLVs if you check the Accounting Reports.

Also take a look at: Configure Device Sensor for ISE Profiling.

Hope this helps !!!

Octavian Szolga · ‎07-04-2021

Hi,

That's another non-obvious thing about profiling.
You want to use Device Sensor to profile your IP Phone.

Device Sensor take CDP/LLDP/DHCP info and sends that info to ISE using Radius Accounting.

But what's not obvious is that in order to send Radius Accounting to ISE for a particular session, you have to 'authenticate' that device.

In your case, you can do something like this:

- create a profiling policy that references only the MAC OUI ('My-Phone-parent' policy = if MAC OUI is/contains my-vendor)

- create an authorization policy that references the above profiling policy and has the following result/authorization profile:

Access-Accept + voice VLAN (if required) + dACL Deny_ANY (no network access; LLDP/CDP is allowed by default for a 802.1x port)

At this point, you just 'faked' a successful authentication in a way that you 'allowed' the session (Radius Access-Accept) but actually you don't allow any traffic (Deny_ANY dACL). For this session, the switch will send accounting data

Accouting data means CDP/LLDP info that ISE receives which you use in a new child profiling (parent would be 'My-Phone-parent').

This profiling child policy will reference the extra LLDP info that you want, and will trigger a CoA event when that info is recevied by ISE.

ISE will rescan authorization rules and will match an upper authorization rule where you actually reference the new child profiling policy.

BR,

Octavian

hslai · ‎07-05-2021

> ... how am I supposed to profile the device based on LLDP attributes if I can't send them via access-request packets?

> ... am I missing something?

No, your configuration looks fine.

Profiling works asynchronously and the attributes are not sent as part of access requests. Although you are getting the attributes via accounting updates, ISE may also get them via SNMP queries of the network devices by ISE. Still, Octavian is correct that the endpoint needs be online with an active session. If ISE classifying the endpoint with a new profiling policy or group while the endpoint is online, if the change of the profiling policy or group evaluated to a new authorization policy rule, and , if ISE profiling CoA action is to re-auth or port-bounce, then ISE will trigger a CoA. If the endpoint re-authenticates later, it will also use the updated profiling policy.