Issue with Idle Timeout and MAB Authentications

[paul]

I am having a weird situation that I wanted to check if any one has run into.  I am working in a non-Cisco phone environment and have had to enabled idle-timeout one some of my authorization profiles to ensure MAB devices behind phones don't keep authenticating even after they disconnect.  On some of the sessions that have idle timeouts (even when not behind phones), I am seeing them get stuck in this:

show auth session int fa 5/0/13
Interface: FastEthernet5/0/13
MAC Address: Unknown
IP Address: Unknown
Status: Running
Domain: UNKNOWN
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-auth
Oper control dir: in
Session timeout: N/A
Idle timeout: N/A
Common Session ID: 0A22FF8C000134AAA3648C1D
Acct Session ID: 0x00016EBA
Handle: 0xD300083B

Runnable methods list:
Method State
dot1x Failed over
mab Running

Now an Unknown MAC address usually means the switch hasn't learned the MAC address, but we can see the switch has:

USBELC3_SWT01#show mac address-table int fa 5/0/13
Mac Address Table
-------------------------------------------

Vlan Mac Address Type Ports
---- ----------- -------- -----
146 480f.cf61.e1dc DYNAMIC Fa5/0/13

Now if you have worked with ISE long enough a key thing should stick out in the above command.  Once you deploy ISE to a switch port learned MAC addresses are always STATIC and never should by DYNAMIC.  Yes we have done "clear mac address-table dynamic" many times and we can watch the device MAB authenticate just fine and the MAC address goes to STATIC, but the next day we come back and it will be back stuck in the Unknown state again.

I haven't run into this before but I rarely have to use idle timers.  I currently have the timer set for 5 minutes.  I am debating raising it to something very high like 4-8 hours, but not sure.  It has to be idle timer related.  Most of these switches are 12.2(55)SE12.

Has anyone run into something like this before?

[ognyan.totev]

Hi @paul  i have some trouble before with same version of the switch ,but i dont think this is from the switch site. In my case i saw that 2 port that they had this problem they got CRC errors , we send local guy and he change the cables i shut and no shut the port and problem doesn’t exist anymore.

[paul]

I think idle timeout is just busted. On the 12.2(55)SE12 switches it just counts down from 300 to 0 and clears the sessions every 5 minutes.  There is traffic going on all the time. 

On 15.2.x switches I don't even see it working at all.  I see this on the authentication session:

Server Policies:
Idle timeout: 300 sec

But if I unplug the device behind the phone the MAC address never clears out.  I don't see any countdown idle timer either.

Looks like TAC case fun.

[Arne Bier]

throwing something out there ... non Cisco phone means no CDP.  I have a vague recollection about CDP helping in this instance as a surrogate to help the switch purge those MAC addresses because the switch never sees the physical link go down - it has no way of knowing the host has gone.  But on Cisco devices with CDP enabled this does work.  Perhaps there is a similar thing with LLDP?

Do you have re-authentication timers set for those ports?  I thought re-auth takes care of these things, no?

IBNS 2.0 has a probe feature that check every now and then if the MAC is still there (via arp queries) - but that version of IOS pre dates IBNS :-(

I am busy skilling up on the finer points of wired 802.1X and I am finding it quite intensive, when compared to wireless.  No wonder people are installing more wireless these days.

[paul]

We use reauthenticaiton on every wired profile, but with MAB there is no query to the end device.  If the link is UP the switch just sends the MAC address in to be authenticated again which is why you need to implement idle timers in a non-Cisco phone environment if you want to age out disconnected devices behind phones.

[Arne Bier]

Just out of interest, when you return an Authorization Profile containing the Idle-Timeout value, do you apply that across the board to any client auth that is a PC/Workstation?  Is there any way to tell that this host connected to a phone?  If not, then I guess you have to apply it across the board ?  How do you do that in practice?

[paul]

I typically apply it to authorization profiles that could be reasonably be behind a phone.  There is no way to tell that I know of.  So in this case I am applying it to my domain computer rule and my Monitor Catch All/Limited Access rule.