Showing results for 
Search instead for 
Did you mean: 

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.


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.


Cisco Employee

It might depend on the IOS-XE release or platform or ISE release. Also check the filter-list used for LLDP.

In discussing Device Sensor Filter Lists and MUD Profling, I found our teams tested it working with ISE 2.6 and IOS-XE 16.9.1 on 3850.

No filter configured. I assume this means all the information should be transmitted to ISE. Is this correct?

Cisco Employee

Yes, I would have assumed so.

Summing up:

1. The phone information is in the switch LLDP cache

2. No device-sensor filter-list lldp is configured (all the information is kept)

3. mac address-table notification change, mac address-table notification mac-move and snmp trap mac-notification are configured

4. snmp queries are enabled

It should work but it doesn't ...

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

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

Content for Community-Ad