EAPOL Timer - Cisco 3850

[Mark H]

Hi everyone,

We're utilising ISE for our wireless network with Cisco 3850 switches and we experience a lot of errors in ISE such as the supplicant stop responding during authentication, but retries immediately.

I suspect we need to increase some EAP timeouts. I have found instructions to complete this on the older WLC, but unsure how to complete it on a Cisco 3850. Any suggestions? Below are the instructions on completing it on a WLC.

https://supportforums.cisco.com/document/46101/eap-timers-wireless-lan-controllers

Thanks,

Mark

[nspasov]

Hi Mark-

Are you seeing those errors in ISE or the Switch? Also, what version of code are you running on both the 3850s and ISE.

Thank you for rating helpful posts!

[Mark H]

Hi Neno,

I see the errors within ISE. For ISE, I'm running 1.2 Patch 13. I have a mix of software versions for our 3850 Switches, 3.3.3, 3.3.4 or 3.6.0.

Kind regards,

[nspasov]

Can you also post the exact error message that you get from ISE? Also, is it affecting any of the authenticating machines/users or are things working as expected?

Thank you for rating helpful posts!

[Mark H]

Hi Neno,

Attached are some of the error messages we see in ISE, we'll get a few hundred of these a day. Mainly from mobile devices such as iPhones, so my guess was that it's due to two things. That the supplicant on mobile devices are pretty terrible and the EAP timers are timing out quicker then the device can respond.

Laptops seem to be able to authenticate fine, but devices such as tablets and smartphones will spin their wheels trying to connect. But if you cancel the connection and try again, sometimes it will then work just fine.

Thanks for your help.

[nspasov]

Thanks for the details Mark! I have seen this issue before with:

- Windows clients that had either misconfigured supplicants or missing some dot1x related patches

- Apple/iOS based devices when they would roam from one ISE-PSN to another and had to accept the ISE certificate

With that being said, can you share some more details on:

- Type of authentication that you are performing? (I am assuming PEAP but just want to confirm)

- What type of Certificates do you have on ISE? Public, Private, Wildcard, etc?

- What type of deployment do you have? Distributed, dual, etc?

Thank you for rating helpful posts!

[Mark H]

Thanks Neno, I appreciate your responses.

We only see these errors when authenticating via PEAP (MSCHAPv2), this is for our 'BYOD'. We also use EAP-TLS for 'corporate' access but do not see these errors using that authentication method, but they are all managed devices that are up to date and controlled via group policy.

We're utilising a public certificate from Thawte The common name is ise.domain.com but we have *.domain.com in the SAN for the certificate too. I've also imported the whole certification path in to ISE as well.

I might be getting the terminology wrong here, but we have a dual distributed deployment. We have two policy nodes, one in each data centre. These policy nodes are in a radius group on the 3850 switches, we're load-balancing these using "load-balance method least-outstanding batch-size 5". Let me know if you want me to clarify this.

We now have NetScaler load balancers, so we could actually target the netscaler for radius and have them ensure only one policy node is used. Would this be the best approach?

Thanks.

Edit: Kako si

[Mark H]

I think this issue is occurring because ise.domain.com is not a trusted authentication server on iOS devices.

I just watched BRKSEC-3697 - Advanced ISE Services, Tips and Tricks from Cisco Live 2015 Milan by Aaron Woland (great session), which lead me down the patch of either having to deploy the certificate or add the name of the ISE server as trusted within the wireless profile. Trusting the certificate on the device isn't good enough.

I'm working with our MDM engineer at th emoment to deploy this, I'll report back to this thread once I know the result.

[nspasov]

Hi Mark and sorry for the delayed reply but I have been very busy with work :) I was actually going to suggest you watch that session from Mr. Woland but wanted to understand your environment/issue better. I saw that session a couple of years ago in Orlando and it was definitely helpful!

So yes, iOS devices will always prompt the user (at least once) to trust a certificate whether or not the certificate was signed by a public (well known) or a private CA. So you can have a super expensive certificate that was signed by VeriSign and the iOS devices will still prompt the user at least once.

With that being said, if you have a way to "push" this to iOS devices via MDM then you could definitely avoid this. 

Let me/know how it goes.

Thank you for rating helpful posts!

Edit: Dobre sam, kak si ti? :)