cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Announcements
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

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.

729
Views
15
Helpful
19
Replies
Highlighted
Beginner

ISE Profilling - LLDP device-sensor cache updates using RADIUS

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

Highlighted

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

Highlighted

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
Highlighted

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

Highlighted

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

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.

Highlighted
Cisco Employee

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

Highlighted

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.

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

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

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

Highlighted

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

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

Highlighted

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.

Content for Community-Ad