I'm looking at upgrading a number of WS-C3650-48PD stacks from 03.07.05 to 16.6.6. I'm avoiding Fuji for now in case of any smart licencing issues (many of these switches were purchased as lanbase with ipbase rtus).
I've been doing testing with 16.6.6 and the stack ibns2 radius setup. All works well until I reload the switch and run into the bug CSCvc86691 "When 'dot1x critical eapol' is configured, switch sends EAP failure instead of Success".
As the switch comes online and brings up the interfaces, radius server is briefly unavailable and the switch responds with "failed authentication" to the connected windows 802.1x clients - the Windows clients will then not attempt eap again for 20 minutes.
It appears that "dot1x critical eapol" on 16.6.6 has an additional feature: "dot1x critical eapol block" - this will "Block all EAPoL transaction on Critical Authentication" as opposed to replying with "passed authentication".
The "dot1x critical eapol block" resolves my issue when the switch reloads and seems to have no adverse impact on the 802.1x clients (they authenticate as soon as radius is alive). Is anyone using this "block" feature in production? If so, have there been any issues?
Solved! Go to Solution.
My apologies - 16.6.6 doesn't seem to suffer from the bug CSCvc86691 after all (i've been testing a number of different ios on the switch which led to confusion).
"dot1x critical eapol" works as expected.
Thanks for that - I'll look into device-sensor (snmp-query is used so hopefully that's covered). Hopefully get the bulk of things working - confirmed that vlan-id is sent in access-session authentication requests (used by ISE for profiling), Radius periodic accounting not working but will enable periodic re-authentication to fix that.