Author Topic: Cisco ISE stale wired authentication sessions (Read 147318 times)

gvoden · « **on:** April 06, 2016, 05:51:15 PM »

Hi all,

we are in the middle of rolling out ISE 1.4 on a Cisco 4507 switch access network (NAD's)
We are using the native Windows 7 supplicants on our endpoints for 802.1x. Windows computers are plugged in behind Avaya IP phones. Avaya phones are configured with EAP proxy logoff so that they will notify ISE of any workstation disconnect provided the workstations are setup for 802.1x. The issue is with computers not setup for 802.1x yet, they seem to generate stale authentication sessions that get stuck in "UNKNOWN" domain instead of voice or data. Please advise if you have seen this behavior.

MC · « **Reply #1 on:** April 07, 2016, 11:33:31 PM »

This sounds like a limitation on Avaya phone. Cisco phone is able to inform attached switch when its PC port goes down so the switch can clear session as describe below. Your next option is probably relying on device tracking to help detecting device leaving the network. Do you have device tracking turned on?

Cisco Discovery Protocol (CDP) Enhancement for Second Port Disconnect—Allows a Cisco IP phone to send a CDP message to the switch when a host unplugs from behind the phone. The switch is then able to clear any authenticated session for the indirectly connected host, exactly the same as if the host had been directly connected and the switch had detected a link down event.

gvoden · « **Reply #2 on:** April 08, 2016, 05:36:39 AM »

Yes we've got ip device tracking turned on. If the computer is using dot1x and disconnects from the network, the authentication session immediately disappears from the switch (due to the proxy logoff feature that we enabled on the Avaya phones). Plugging in and unplugging a non-dot1x enabled laptop results in stale sessions on the Cisco siwtch. Doing this multiple times results in more "stuck" sessions.

taa02ca1#show auth sessions in fa7/33

Interface MAC Address Method Domain Status Fg Session ID
----------------------------------------------------------------------
Fa7/33 68f7.2800.0005 N/A UNKNOWN Unauth 0000000000003FF117E9B360
Fa7/33 68f7.2800.0004 N/A UNKNOWN Unauth 0000000000003FF017E909E8
Fa7/33 68f7.2800.0001 N/A UNKNOWN Unauth 0000000000003FED17E6CA90
Fa7/33 2cf4.c5ef.1b00 mab VOICE Auth 0000000000003FE017810824
Fa7/33 68f7.2800.0003 N/A UNKNOWN Unauth 0000000000003FEF17E879C8
Fa7/33 68f7.2800.0002 N/A UNKNOWN Unauth 0000000000003FEE17E7E1E8

Cisco just told us this is a switch bug (CSCtg15739), I am surprised as we just upgraded to their recommended code level. We are using Catalyst 4507's with SUP6L-E and SUP7L-E.

MC · « **Reply #3 on:** April 10, 2016, 09:14:37 PM »

What IOS version are you running on both SUP6 and 7? My understanding is device tracking supposes to take care of this type of situation. Basically once Device tracking declares an endpoint (MAC address) as stale, it should signal the port to clear corresponding auth session. Obviously that did not happen in your case and a bug would explain it.

gvoden · « **Reply #4 on:** April 14, 2016, 07:24:34 AM »

We upgraded to the Cisco recommended versions for ISE 1.4 (as per their published official versions):

SUP7L-E -> IOS-XE 3.6.3E with ROMMON 15.0(1r)SG10
SUP6L-E -> IOS 15.2(2)E3 with ROMMON 12.2(44r)SG10

Now they are saying there is a bug in this code although it was not pointed out originally. Starting to lose faith in this solution.

MC · « **Reply #5 on:** April 14, 2016, 11:11:44 PM »

Since every ISE deployment is different, in your case happens to be an Avaya phone, sometimes it is hard to say if you will run into a bug or not. This is why it is important to do a Proof-of-Concept and flush out all the issues before rolling out ISE. Hopefully the bug you ran into is already a work in progress for Cisco otherwise it might take a while to get a fix.

gvoden · « **Reply #6 on:** April 21, 2016, 07:40:13 PM »

This appears to be an issue in "open mode". As clients who do not match an authorization rule are "denied" access, the switch holds onto the sessions and does not expire them. Waiting to hear back on the code revisions and will post the outcome.

MC · « **Reply #7 on:** April 22, 2016, 12:04:51 AM »

open mode as in you have 'authentication open' command configured on the interface so client is allowed access regardless of pass or failed authentication?

gvoden · « **Reply #8 on:** April 23, 2016, 08:59:15 AM »

Correct, open authentication. Cisco states this is the bug ID You are not allowed to view links. Register or Login

As a workaround we changed the default deny rule to "allow", this allows the Windows machines that don't have the supplicant to still be allowed on and then the switches can process the session properly. I think this behaviour won't demonstrate itself in closed mode....

Search

User Info

Author Topic: Cisco ISE stale wired authentication sessions (Read 147318 times)

gvoden

Cisco ISE stale wired authentication sessions

MC

Re: Cisco ISE stale wired authentication sessions

gvoden

Re: Cisco ISE stale wired authentication sessions

MC

Re: Cisco ISE stale wired authentication sessions

gvoden

Re: Cisco ISE stale wired authentication sessions

MC

Re: Cisco ISE stale wired authentication sessions

gvoden

Re: Cisco ISE stale wired authentication sessions

MC

Re: Cisco ISE stale wired authentication sessions

gvoden

Re: Cisco ISE stale wired authentication sessions

Related Topics