https://community.cisco.com/t5/network-access-control/device-sensor-and-automated-tester-behavior/m-p/3889800#M471506 It should not behave that way. The command should only restrict automate tester from sending probes on 1813/1646. Seems like a bug to me.<BR /> Sun, 14 Jul 2019 07:40:51 GMT Surendra 2019-07-14T07:40:51Z https://community.cisco.com/t5/network-access-control/device-sensor-and-automated-tester-behavior/m-p/3889776#M471505 <P>I've been developing and testing some new IBNS 2.0 configurations on a 3850 with 16.6.6/16.9.3a and came across some odd behavior/interaction with device sensor and the automated tester.&nbsp; I have a TAC case open on this (SR# 687085849), and I am trying to determine if this is the expected behavior or a bug. I have asked TAC but have not heard back, so anyone know if it should behave this way?&nbsp;</P> <P>What I have found is that when "automate-tester username NAD-Tester ignore-acct-port probe-on" is added to the radius server configuration, learned device sensor attributes that appear in the cache do not get forwarded to ISE.&nbsp;</P> <P>If I use "automate-tester username NAD-Tester probe-on", removing the "ignore-acct-port", then device sensor attributes show up in ISE, doesn't seem like it should act this way.&nbsp;</P> <P>&nbsp;</P> <P><STRONG>Radius server example where device sensor data is not sent</STRONG><BR />radius server ISE-VIP-A<BR />address ipv4 10.1.1.1 auth-port 1812 acct-port 1813<BR />pac key xxxxxxxxxxx<BR />automate-tester username NAD-Tester&nbsp;ignore-acct-port probe-on</P> <P><STRONG>Radius server example where device sensor data is forwarded as expected</STRONG><BR />radius server ISE-VIP-A<BR />address ipv4 10.1.1.1 auth-port 1812 acct-port 1813<BR />pac key xxxxxxxxxxx<BR />automate-tester username NAD-Tester probe-on</P> <P>&nbsp;</P> <P>This is the same as configured in the ISE Secure Wired Access Prescriptive Deployment Guide, so quite a few deployments could have this issue and not even realize their profiling is hindered.&nbsp;&nbsp;<BR /><A href="https://community.cisco.com/t5/security-documents/ise-secure-wired-access-prescriptive-deployment-guide/ta-p/3641515" target="_blank">https://community.cisco.com/t5/security-documents/ise-secure-wired-access-prescriptive-deployment-guide/ta-p/3641515</A></P> Sun, 14 Jul 2019 00:38:01 GMT https://community.cisco.com/t5/network-access-control/device-sensor-and-automated-tester-behavior/m-p/3889776#M471505 Damien Miller 2019-07-14T00:38:01Z https://community.cisco.com/t5/network-access-control/device-sensor-and-automated-tester-behavior/m-p/3889800#M471506 It should not behave that way. The command should only restrict automate tester from sending probes on 1813/1646. Seems like a bug to me.<BR /> Sun, 14 Jul 2019 07:40:51 GMT https://community.cisco.com/t5/network-access-control/device-sensor-and-automated-tester-behavior/m-p/3889800#M471506 Surendra 2019-07-14T07:40:51Z https://community.cisco.com/t5/network-access-control/device-sensor-and-automated-tester-behavior/m-p/3889937#M471508 That agrees with how I feel the command/feature should work. I'll continue to work the TAC case and follow up when complete. Sun, 14 Jul 2019 19:27:58 GMT https://community.cisco.com/t5/network-access-control/device-sensor-and-automated-tester-behavior/m-p/3889937#M471508 Damien Miller 2019-07-14T19:27:58Z