This isn’t a Cisco ISE bug but it could affect ISE deployments. A customer had recently deployed several Cisco 3850s with Multigigabit at their headquarters. Initially, the switches were deployed with IOS XE 3.7.5. We tested the Cisco ISE configuration on those switches (Monitor Mode) and everything worked properly. The customer was able to authenticate users and endpoints using 802.1x and MAB as well as profile connected devices.
The customer ran into an issue with the IOS XE 3.7.5 code that caused link flaps. Another engineer engaged TAC to troubleshoot. When they discovered it was a bug that only affected 3850s with Multigigabit, the recommended fix was to upgrade to Denali (16.3.x). One stack was upgraded to 16.3.5b in order to verify that the link flap issue was resolved. We needed to verify that all authentication functions continued to work properly because of the IOS upgrade.
It was discovered that 802.1x authentication was no longer working. Checking the ISE RADIUS live logs showed that only MAB was coming through. There was no 802.1x authentication request coming from the switch. The switch logs showed the following:
Jan 22 09:22:23 CST: %SESSION_MGR-5-FAIL:Switch 1 R0/0: smd: Authorization failed or unapplied for client (38C9.860E.E745) on Interface GigabitEthernet1/0/6 AuditSessionID 0A4A05640000060F1E764F7C
This was repeated every time the client disconnected and reconnected. A quick search in Bug Tracker found bug ID CSCvg07470. This bug mostly matched our issue even though MAB was working. The bug was logged against a 3850 running 16.3.3. We opened a TAC case to see if the customer is seeing the same bug in 16.3.5b. It was determined that the customer was in fact hitting that bug. Unfortunately, according to the TAC engineer, there is no current Denali release that corrects this issue.
Because of the link flap issue being resolved in 16.3.5b, the rest of the switches will need to receive the upgrade. The good news is that the customer is only running Cisco ISE in Monitor Mode so no endpoint/user access is affected. The bad news is that the roll out to Low Impact and Closed mode will be delayed until a fix for this new bug is put into place.
Update 2018/01/29: It turns out that the issue I was running into is a configuration issue. The TAC engineer double checked my configuration and found that I was missing “dot1x pae authenticator” from the port config. This was not a required command when the switch was running 3.7.5 and C3PL was enabled but it is required in Denali.
So there you go. Lesson learned. I’ve made sure my configuration templates were updated accordingly.