ISE and 3850 3.2.2SE - Authenticating Wrong Domain and More

[Mark H]

Hi everyone,

Have been forced in to accepting the new session aware networking commands and I am running in to a few issues. I finally have a service policy that is authenticating dot1x and MAB (we use EAP-TLS for the desktop and MAB for the phone), however I am experiencing two major issues:

1. When attempting to authenticate both devices, the port has a port-security issue and moves to an err-disabled state.
2. When attempting to authenticate just the phone with the service-policy, the phone is authenticated in to the data domain. However, if I use a service-policy that authenticates just MAB the phone will be correctly authenticated in to the voice domain.

Can anyone give me some pointers in the right direction? Attached is the interface configuration and service-policy I'm using.

Thanks,

Mark

[Saurav Lodh]

Post the below output

#show authentication sessions interface XX

[Mark H]

Hi salodh,

Please find attached the following:

1-Device.txt = The output when only authenticating MAB and one device. As you can see it starts unauthorized and once authorized remains on the data domain despite receiving the correct service template I have configured that allows voice domain access.

2-Devices.txt = This is what occurs when authenticating both dot1x and mab in a sequential manner for two devices. Once the second device is authenticated there is no access session for it, as you can see the port is put in to an err-disabled state.

Thanks,

Mark

[nspasov]

Hi Mark. I have never deployed dot1x in a manner that you have done it (service-policy) so I might need more info to better understand your deployment.

However, I would highly recommend that you upgrade the code of your switch. I have done several deployments with 3850s and I have had all kinds of issues with older code. You should be running 3.3.4 if you can. Perhaps you can upgrade one switch and test it but outside of dot1x there has been tons of other bug fixes related to XE. 

Thank you for rating helpful posts!

[Mark H]

Thanks Neno, planning to give it a go on 3.6.0 shortly. If that fails I'll roll it back to 3.3.4 and give that a go as well.

[nspasov]

I have had a good run with 3.3.4 and it is currently ours and Cisco's recommended version but if you want to try 3.6 then be it :) Nonetheless, please let us know if that fixes the issue. 

Thank you for rating helpful posts!

[Mark H]

Will do. We have 3.6 on majority of our production switches, we made the jump to it in order to resolve some SNMP temperature reporting issues. Unfortunately it was just before 3.3.4 got released!