I guess so, but effect of the bug is devastating. So if we hit it, then we're screwed... I'd prefer to do this in a controlled manner. By the way, it means we'll finally connect CIMC to the network and will have in-band access to the console via virtual KVM :) Not a bad thing. ... View more

@Leo Laohoothank you! Very helpful.   I guess we will use the following approach. We have HA N+N FlexConnect deployment. We will force APs to failover to secondary WLC, we can then do whatever we want to primary WLC. In SSO pair, we will break the HA, upgrade standby unit, build HA, failover, break HA, upgrade standby unit, build HA and failback to original state.   In both cases it will be seamless. The only reason to break HA is to make sure we are in control (in case a physical intervention will be required, or reboot of whole UCS).   I've just arranged KVM cables (we threw ours away as no one ever thought we will need to connect monitor and keyboard to WLC!). Checked the links you sent me, I think we're good. I have assigned IP addresses to CIMC in SSO using temporary DHCP scope and then changed to static and removed DHCP scope. This one is a bit worrying (CSCvj80941) and basically forces to approach this change with physical presence at site.   Regards ... View more

Hi @FvMoll    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. ... View more

Ok guys @kthiruve @Jason Kunst  I had to reach out Cisco TAC. Here's the TAC response   ================= Kindly note that it is possible to force authorize as session without authentication to trigger RADIUS accounting in absence of authentication with old version, There is change in behavior after 15.0(2)SE. Till 15.0(2)SE​, monitoring sessions were authorized by default. So, we used to see device-sensor accounting for monitoring sessions. After 15,0(2)SE, monitoring sessions are unauthorized by default. Consequently, you won't see device-sensor accounting for monitoring sessions.   So, we need to have a dot1x/mab session to get the device sensor information into ISE, based on that, this document should be upgraded. =================   Everything I said above is indeed valid - Radius probe with Device Sensor requires valid Authentication/Authorization session, otherwis there's no Accounting. I have asked TAC engineer to reach out to BU to make sure all documentation is up to date. I will also get in touch with our Account Manager to make sure this really happens.   At least this is now clear, the behavior is not buggy but rather expected. And... this discovery makes our project a bit more challanging as I am unable to rely on Radius probe only :(   ... View more

@mmalwatteyes. It does seem like every Cisco's documentation on Device Sensor was misleading so far. I have raised with Cisco TAC and once they conffirm my observations I will be in touch with BU through our Account Manager to make sure they update everything to stop this bad practice. Always liked Cisco documents for a level of detail and truthfulness... until now :)   ... View more

Ok, in that case let me know what is wrong with my configuration (taken from Catalyst 3850, running Everest 16.6.5)   aaa group server radius LAB-ISE-2x  server name LAB-ISE-2x-1  ip radius source-interface Vlan1 ! aaa authentication login default group LAB-ISE-2x local aaa authentication enable default enable aaa authentication dot1x default group LAB-ISE-2x aaa authorization console aaa authorization exec default group LAB-ISE-2x local aaa authorization network default group LAB-ISE-2x aaa accounting update newinfo aaa accounting dot1x default start-stop group LAB-ISE-2x aaa accounting network default start-stop group LAB-ISE-2x aaa accounting system default start-stop group LAB-ISE-2x aaa server radius dynamic-author  client 10.255.33.251  server-key 7 <secret> ip dhcp snooping vlan 66,68-71 ip dhcp snooping ! device-sensor filter-list lldp list w1lab-lldp-tlv  tlv name port-id  tlv name system-name  tlv name system-description  tlv name system-capabilities  tlv name management-address ! device-sensor filter-list cdp list w1lab-cdp-tlv  tlv name device-name  tlv name address-type  tlv name capabilities-type  tlv name platform-type ! device-sensor filter-list dhcp list w1lab-dhcp-options  option name host-name  option name default-ip-ttl  option name requested-address  option name parameter-request-list  option name class-identifier  option name client-identifier ! device-sensor filter-spec dhcp include list w1lab-dhcp-options device-sensor filter-spec lldp include list w1lab-lldp-tlv device-sensor filter-spec cdp include list w1lab-cdp-tlv device-sensor accounting device-sensor notify all-changes ! access-session template monitor ! dot1x system-auth-control ! lldp run ! template W1LAB-AP-PORT  spanning-tree portfast  spanning-tree bpduguard enable  switchport access vlan 66  switchport mode access  description WAP ! template W1LAB-UC-PORT  spanning-tree portfast  spanning-tree bpduguard enable  switchport access vlan 68  switchport mode access  switchport voice vlan 70  description PC/VoIP ! interface GigabitEthernet1/0/46  description IP Phone (Astra)  source template W1LAB-UC-PORT ! interface GigabitEthernet1/0/48  power inline port perpetual-poe-ha  power inline port poe-ha  source template W1LAB-AP-PORT ! radius-server attribute 6 on-for-login-auth radius-server attribute 6 support-multiple radius-server attribute 8 include-in-access-req radius-server attribute 25 access-request include ! radius server LAB-ISE-2x-1  address ipv4 10.255.33.251 auth-port 1812 acct-port 1813  key 7 <secret>   Device sensor sees devices on both interfaces:   LAB-S3850-3#sh device-sensor cache int gi1/0/48 Device: f4db.e62e.e63e on port GigabitEthernet1/0/48 -------------------------------------------------- Proto Type:Name Len Value DHCP 50:requested-address 6 32 04 0A FF 42 66 DHCP 55:parameter-request-list 11 37 09 01 0F 03 1C 0C 06 07 1A 2B DHCP 60:class-identifier 16 3C 0E 43 69 73 63 6F 20 41 50 20 63 33 38 30 30 DHCP 12:host-name 15 0C 0D 4C 41 42 2D 41 50 33 38 30 32 69 2D 32 DHCP 61:client-identifier 9 3D 07 01 F4 DB E6 2E E6 3E LLDP 8:management-address 14 10 0C 05 01 0A FF 42 66 03 00 00 00 00 00 LLDP 6:system-description 199 0C C5 43 69 73 63 6F 20 41 50 20 53 6F 66 74 77 61 72 65 2C 20 61 70 33 67 33 2D 6B 39 77 38 20 56 65 72 73 69 6F 6E 3A 20 38 2E 35 2E 31 33 35 2E 30 0A 54 65 63 68 6E 69 63 61 6C 20 53 75 70 70 6F 72 74 3A 20 68 74 74 70 3A 2F 2F 77 77 77 2E 63 69 73 63 6F 2E 63 6F 6D 2F 74 65 63 68 73 75 70 70 6F 72 74 0A 43 6F 70 79 72 69 67 68 74 20 28 63 29 20 31 39 38 36 2D 32 30 31 38 20 62 79 20 43 69 73 63 6F 20 53 79 73 74 65 6D 73 2C 20 49 6E 63 2E 0A 43 6F 6D 70 69 6C 65 64 20 46 72 69 20 4A 75 6C 20 32 30 20 31 33 3A 35 32 3A 35 39 20 50 44 54 20 32 30 31 38 20 62 79 20 76 69 70 65 6E 64 79 61 LLDP 5:system-name 15 0A 0D 4C 41 42 2D 41 50 33 38 30 32 69 2D 32 LLDP 7:system-capabilities 6 0E 04 00 04 00 04 LLDP 2:port-id 4 04 02 01 30 CDP 6:platform-type 26 00 06 00 1A 63 69 73 63 6F 20 41 49 52 2D 41 50 33 38 30 32 49 2D 45 2D 4B 39 CDP 4:capabilities-type 8 00 04 00 08 00 00 00 03 CDP 2:address-type 45 00 02 00 2D 00 00 00 02 01 01 CC 00 04 0A FF 42 66 02 08 AA AA 03 00 00 00 86 DD 00 10 FE 80 00 00 00 00 00 00 F6 DB E6 FF FE 2E E6 3E CDP 1:device-name 17 00 01 00 11 4C 41 42 2D 41 50 33 38 30 32 69 2D 32 On ISE end I have disabled ALL probes intentionally, except Radius   It cannot discover anything   MAB/DOT1X are not configured on interfaces. Once I configure MAB and send Access Accept in case if MAC not found - it works like a charm. It doesn't work though if Authentication is REJECTED   So, back to my original point... Radius Probe requires successful Authorization and it won't work without MAB/DOT1X config on the port. Unless you can tell me I've done something wrong and/or there's a bug in this IOS ... View more

I think this is technically not correct :)   I can deploy pure profiling without using ANY radius at all. So, by its nature, Profiling doesn't rely on Radius   What I tried to point out here is that Device Sensor has changed this as it relies on Radius accounting and hence can only work if switchport has been authorized access.   When I originally started with Device Sensor it took me few days to realize this. In fact, I even had to open TAC case as I didn't understand why I didn't see any profiling data... I think, Cisco can improve this by providing a text in bold against Device Sensor feature in al documentations saying "Device Sensor requires AAA enabled on the port (dot1X/MAB) and requires authentication to actually pass, otherwise Device Sensor information will not be delivered to Cisco ISE as it requires active Accounting session"   Regards ... View more

Thanks   I've read this one (and many more), also attended pretty much every Cisco ISE session on Cisco Live 2018 :) ... View more

I think what many people don't understand is the following   Device Sensor information is delivered to Cisco ISE using Radius. In particular, Radius Accounting.   I give it few minutes to read this few more times, before you will go "Oh... seariously?"   What does it mean? Basically, if you want to rely on Device Sensor, endpoint MUST go through Authentication, and this Authentication/Authorization MUST succeed. No Authentication/Authorization? No Accounting. No Accounting? Nothing is delivered to Cisco ISE, even though switch possesses all information about this endpoint using DHCP snooping, CDP and LLDP databases.   Device Sensor is amazing feature, but you cannot rely on it when port is not configured to authenticate connected endpoint. Period.   Unfortunately, this is not obvious from Cisco documentation and it took me few days in a lab to realize how it really works. Welcome :) ... View more