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.
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.
Solved! Go to Solution.
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.
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...
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.
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.
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
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
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.