cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2121
Views
0
Helpful
2
Replies

retrying authentication failures behind phones

jeremy.hinton
Level 1
Level 1

In the process of testing out our new IBNS 2.0 style dot1x setup, I noticed an issue. I was initially using the policy-map as recommended in the ISE Secure Wired Access Prescriptive Deployment Guide. We have non-cisco (Avaya) phones, and the issue I noticed was when I have a non-dot1x device connected behind a phone. Per the policy, if mab fails, the switch should attempt to re-authenticate after a short while:

 

40 class MAB_FAILED do-until-failure

10 terminate mab
20 authentication-restart 60

 

This is all well and good, and the switch does attempt to re-auth after 60 seconds if mab fails. The problem is that if the failing device is disconnected from the back of the phone, the switch has no idea and will continue to try to re-authenticate using the now-disconnected devices mac address until the port is bounced or authentication is manually cleared.

 

I thought I had a workaround in place with the following change to the policy-map

 

40 class MAB_FAILED do-until-failure
10 terminate mab
20 set-timer REAUTH 60

 

event timer-expiry match-first
10 class TIMER_REAUTH do-until-failure
10 clear-session

 

Instead of just re-authenticating post-failure, this would set a timer for 60 seconds, after which it would clear the failed authentication session. The idea initially seemed to work, in that the switch did not continue trying to authenticate a device that was no-longer there. It didn't work entirely as expected however. I had thought that any new incoming traffic on an unauthenticated port (or rather unauthenticated device/mac on any port) would trigger a new authentication, but it does not. With this config, if a device times out of dot1x and fails mab, the switch will never try to re-authenticate that non-dot1x device until the port is bounced. The device can be sending packets into the switch all day, and the switch will never attempt to re-authenticate it.

 

Does anyone know of a way to configure the switch to re-authencate a failed device, but only if/when it sees packets from that device enter the switchport?

 

Just a side note - we are not using ISE but another 3rd party NAC, so switch-centric solutions (and not ISE based ones) would be preferred

 

 

2 Replies 2

Arne Bier
VIP
VIP

That's quite a useful trick - I will have to remember that :)

I think the issue with non-Cisco phones is that they don't automagically send a proxy-logoff EAP message to the switch. But I find it strange that when you connect a new device to the phone, the phone doesn't notice the "link up" event and then start the supplicant software running in the phone. Perhaps this is an Avaya issue that needs sorting out first.

All Cisco IP Phones and some third party phones provide Proxy EAPoL-Logoff functionality. No special functionality is required from the switch since the EAPoL-Logoff message is fully supported as per the IEEE standard. While effective for IEEE 802.1X-authenticated endpoints, Proxy EAPoL-Logoff will not work for MAB or WebAuth since these authentication methods do not use EAP to authenticate. Another method, such as Inactivity Timer, must be used to ensure that MAB sessions are appropriately cleared.

 

Use authentication timer inactivity <x> to clear the session after x minutes of the switch seeing no traffic from the endpoint.