Switch device sensors and access-reject

I’ve seen this a couple of times at customer locations. They are using a default deny if the endpoint fails all other authorizations rules. When they check for endpoint details (profiling), only the top level profile (ie Cisco-Device) was assigned. The child profile is not analyzed so therefore any authorization rule that relies on that child profile is never hit. This was especially an issue with IP phones, both Avaya and Cisco phones, because the CDP/LLDP info was not complete. Why?

The issue was caused by the access-reject triggered in the deny access authorization result. Device sensor data utilizes the RADIUS accounting packet to deliver that information to the Cisco ISE node. When you send an access-reject, you end all accounting for that session. The only way to trigger a new session is for the endpoint to disconnect and reconnect or a session timeout to occur. A new session will trigger the RADIUS authentication and accounting to start again which will send more information to the ISE node.

So how can you get around this? The way I’ve found is to utilize an access-accept authorization profile that utilizes a simple dACL:

# Allow DHCP
permit udp any eq bootpc any eq bootps
# Deny all other access
deny ip any any

Once that was implemented, accounting will continue even though the endpoint has no real network access (DHCP only). The customer was able to see the proper child profile hit which allowed the correct authorization rule to be triggered. If you are concerned about DHCP access, or only concerned with received CDP/LLDP info, you can remove the line to allow DHCP.

Share this post:

2 comments

  1. Thanks, this really helped us as we were also experiencing devices only being assigned the top profile and ISE seemingly not receiving the LLDP/CDP attributes even though the switch is configured to send them. Once we implemented your work around, devices were being profiled correctly again.. is there a way of implementing this long term without having the effect of everything in the radius log showing a status of authorised? or should this method only be used during the profiling stages of implementation. Currently we have changed the default policy to have the result policy outlined in your work around.

    1. I am not aware of any other way at this point outside of just creating a rule specifically to allow profiling only so you can run reports filtering that out. From what I can tell, and I’m no switch expert, it would take something in the IOS/IOS XE code to allow accounting to continue even with an access-reject.

Leave a Reply

Your email address will not be published. Required fields are marked *