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.
TAC is pretty much correct. However with newer IOS platform code, it's possible to perform local authorization using IBNS 2 and to send device sensor data to ISE via RADIUS accounting interim updates.
@Tymofii Dmytrenko thanks! Yeah I wasted a bit of time with this too. Then got TAC involved since device sensor wasn't working as I had expected, and we had an snmpquery probe issue as well. Funnily enough even TAC at first wasn't too sure about device-sensor, only after I showed them your discussion about authentication needing to pass first for it to work, did they confirm the behaviour. looks like there is a major misunderstanding with this feature.
Anyway I did some further tests and also confirmed device-sensor via radius probe works only when radius access-accept received. Originally I had my default mab authz policy with the default "DenyAccess" which is an Access-Reject. I created a new authz profile using Access-Accept with a deny ip any any dACL, applied it to the authz policy and then radius probe starts working.
Same issues here, I also created a "pre-device-sensor" rule in my MAB policy to do an "Access-Accept in conjunction with a DACL "Deny ip any any". This is enough to get Accounting up and running.
I should have found this thread earlier, it would have saved me some major headaches!
@Tymofii DmytrenkoDid you receive any updates about it? Will Cisco update their documentation?
The latest update I've got from TAC before we closed the case was this one...
Kindly note that I had engaged further resources to re-open this enhancement request “CSCvn03049 Need to add note that device sensor info is dependent on dot1x auth/authz” and currently is just employee visible and sent their an email to let it as customer visible if possible, so now the document should be updated based on this enhancement bug.
Hope this is helpful.
I have the opposite issue.
All of our switches are configured to perform dot1x or mab authentication but we did not configure device-sensor
We are gradually migrating from ACS and ISE and I doscovered that ISE endpoint database is populated with endpoints that did not undergo any authentication.
Looking deeper at the issue I found that those endpoints where created becuase of some switches sending accounting packet labelled with "radiusprobe"
I suppose this is because of this default configuration
SWITCH#show running-config all | in device-sen
device-sensor notify new-tlvs
For instance on ISE endpoints t database I can find mac addresses of distribution switches interfaces connected to dot1x access switches.This is quite puzzling because that "accounting only" endpoints are shown by ISE as connected endpoints.
I am pretty sure they are not consuming a base licenses but their presence could be quite annoying (not to speak of the fact that those switches are sending those accounting packets even for wireless endpoint connected to flex connected ap ....)
I have opened a SR with TAC but the engineer is not able to address the issue.
Does anyone know if
device-sensor notify new-tlvs
may actually be the cause of the issue and why Cisco does not document this configuration?
Hi For us, none ISE device ports started populating as radius probe after we added the DHCP helper address on the SVI to point to ISE.