cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2595
Views
15
Helpful
19
Replies

ISE Profilling - LLDP device-sensor cache updates using RADIUS

ajtm
Level 1
Level 1

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.

 

1 Accepted Solution

Accepted Solutions

hslai
Cisco Employee
Cisco Employee

Is there a way to understand what information is send on SNMP query response packets?

We should be able to see the info in the SNMP responses in the wired packet captured on SNMP traffic between the ISE PSN and the NAD, if using SNMP v1 or v2c.

In this particular use case that snmpQuery triggered by either snmpTrap or account start, there are some known issues -- CSCvm70858 and CSCuw50171. I think it best to get a Cisco TAC case open to help gathering debug data and/or recreate.

View solution in original post

19 Replies 19

hslai
Cisco Employee
Cisco Employee

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

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...

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

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

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.

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
Cisco Employee
Cisco Employee

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

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
Cisco Employee
Cisco Employee

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

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

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

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
Cisco Employee
Cisco Employee

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.

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: