ISE Profilling - LLDP device-sensor cache updates using RADIUS

[ajtm]

Trying to use logical profile based on LLDP system-capabilities information in authorization rule but it doesn't work because information is only transmitted to ISE in RADIUS Attribute Value Pair inside accounting request, and the accounting only happens after an RADIUS access-accept.

The only way I can workaround this issue for now is using a rule with temporary access so it can triggers the RADIUS accounting packet to transmit the LLDP cache information to ISE.

[hslai]

Yes, this is how profiling works in general, but not specific to device-sensor or LLDP. See Access Policy and Device Configuration Impact on Profiling

[ajtm]

I understand the concept of allowing some traffic if we use, for instance, DHCP probes.

But, in this case we have the profiling information available the moment we connect the device (phone) - I can see it in the LLDP cache. It would be nice if we could transmit the information in the RADIUS access request...

[Mohammed al Baqari]

With device sensor I don't think this will work because as you said radius
accounting will be sent only after access-request. If you use SNMP polling
in ISE as a probe then you might get it working because SNMP polling can
take place independently from access-request.

**** remember to rate useful posts

[ajtm]

I have snmp trap mac notification configured and I can see snmp traffic between NAD and PSN but information is not being updated!

[Mohammed al Baqari]

Agreed but if you use SNMP query probe then the switch can send CDP info in
the SNMP response which might speed the profiling process compared to
radius accounting packet which has to wait till access-request is sent.

[ajtm]

I can see SNMP traffic when I connect the phone (trap and then query) but I'm unable to decode what information is being transmitted to ISE.

[Parag Mahajan]

your approach is correct. We also use same solution. temporarry access - DNS, DHCP and ISE access

[ajtm]

Yes, DHCP probe works fine but I was trying to avoid temporary access. LLDP cache info should be transmitted in SNMP when the device is connected. MAC move/Link trap  and then SNMP query. I can see SNMP traffic but not able to understand what information is being transmitted.

[hslai]

With the profiling component in DEBUG, we may check profiler.log for details of ISE profiling.

Even with SNMP probe, the endpoint needs online for ISE to gather data. The SNMP query triggered by SNMP trap will check whether the endpoint has an active session in ISE. The periodic SNMP queries to the NADs may gather endpoints based on ARP cache and other info such as CDP or LLDP, regardless of active sessions.

Back to device-sensor, IBNS 2 may allow endpoint access locally without auth against ISE in order to send profiling data.

policy-map type control subscriber dsensor-updates
 event session-started match-all
  10 class always do-until-failure
  10 authorize

[Damien Miller]

Is that true even if one was to add "access-session monitor" to the global config? Maybe I misunderstood the command.

[hslai]

AFAIK IBNS 2 is not sending the device-sensor data via RADIUS accounting interim updates unless the endpoints authorized, either locally or by ISE.

[ajtm]

I've just realized that profiling is working fine for Cisco Phones but not for Alcatel Phones.

Cisco Phones are initially identified as Cisco_Devices and subsequently identified as Cisco-IP-Phone-xxxx

But Alcatel Phones stay classified as Alcatel_Devices (OUI policy)

In profiler.log I can see:

On Cisco Phones: CDP and LLDP Attributes, provided by RADIUS Probe

On Alcatel Phones: OUI provided by SNMPTrap Probe

In packet captures in Cisco Phones I can see two RADIUS access-rejects and then one access-accept. This packet includes AVP profile for Cisco-IP-Phone-xxxx

[hslai]

Great. You are getting closer.

If Alcatel phones not providing CDP/LLDP attributes to id them as phones, then we need either look for another attribute/pattern or whitelist them.

[ajtm]

I can see LLDP information of the Alcatel phone in the switch:

SW_POC_Torre_C#show device-sensor cache all
Device: 0080.9f57.640e on port GigabitEthernet1/0/17
--------------------------------------------------
Proto Type:Name Len Value
LLDP 127:organizationally-specific 23 FE 15 00 12 BB 0B 30 30 3A 38 30 3A 39 66 3A 35
37 3A 36 34 3A 30 65
LLDP 7:system-capabilities 6 0E 04 00 20 00 20
LLDP 0:end-of-lldpdu 2 00 00
LLDP 3:time-to-live 4 06 02 01 E0
LLDP 2:port-id 9 04 07 03 00 80 9F 57 64 0E
LLDP 1:chassis-id 9 02 07 04 00 80 9F 57 64 0E

This information is not being transmitted to ISE.