ISE & EXOS Switch CoA failed - Missing Attribute

[StefanSeubert44470]

Hello Community,
We are in the process of switching from Extreme Networks NAC solution to Cisco ISE.
Most of the switches are also replaced with Cisco 9300 switch.
Nevertheless, about 100 Summit X440-G2 switches still need to run for a few years and authenticate endpoints against the ISE in the future.
We already have a network device profile for EXOS which works. Only the CoA does not work properly.
Meanwhile Exos also supports CoA by radius, but needs special radius attributes in the CoA request.
These are also configured in the Network Device Profile.

If a CoA is now executed, the radius attribute Filter-ID is missing and the switch sends back a CoANAK.

In the Authorization Profile the Radius Attribute is configured.

If I set the identical string in the Network Device Profile, the Radius Attribute will be packed into the CoA Request.

In this case CoA is working on the Exos Switch like expected. 

But this configuration doesn't make sense, because the same Exos policy would be applied to every Reauth from every Endpoint if it is configured fixed.

For my understanding the ISE has to add the filter ID from the new Authorization Profile into the CoA Request?
Or do I have to write something else here as value?

If I connect an end device to the Exos switch, the correct filter ID from the authorization profile is transferred, depending on which authorization rule applies. Only with the Reauth it does not happen.

I have also tried to simply write a 0, but here I have the same result.

Hopefully someone has an idea about this behavior.

Thanks for your help

[MHM Cisco World]

you can push the ACL from ISE or push filter-ID  from ISE
push the ACL from ISE meaning the ACL is config in ISE and push to SW 
push filter-ID from ISE meaning the ACL is config in SW and ISE push only the name 

try push the ACL from ISE

[StefanSeubert44470]

Hi
I don't know if I'm misunderstanding something.
Since we need to send the CoA to an Extreme switch and it expects the Filter-ID attribute, I think ACL is not an option.
On the switch the policies are configured and the switch applies them. The name is stored in the string.
Example:
Enterasys:version=1:policy=FatClients

But I have activated the option in the Network Device Profile

In the Authrization Profile I had the possibility to activate the option as well. Unfortunately it is not possible to store the above mentioned string there. It is always truncated to FatClients. I added the whole string. After saving, closing open it again This ist what the GUI does.

But also with this, the filter ID attributeis not included in the CoA request.

[Arne Bier]

Hi @StefanSeubert44470 

It looks like a bug in ISE with the Network Device Profiles not retaining the Filter-ID attribute for that session. 

The fact that your Wireshark showed Filter-ID as missing when you asked ISE to send the contents of the Filter-ID for that session, would imply (in my mind) that the string was not found, and hence, ISE didn't include it in the CoA. But when you hard-coded a string there, it dutifully sent it.

I don't know of a way to dump the RADIUS dictionary for that session at run-time - but that would be the answer (inspect the Dictionary to see if the Filter-ID attribute remains in memory)

Perhaps an Endpoint Debug from start to end (including the auth, accept and CoA) could reveal something.

If nothing found in Endpoint Debug then you should open a TAC case - great investigative work, by the way !!

[StefanSeubert44470 · Accepted solution]

Hi @Arne Bier 

thank you ;-), yes TAC Case is already open and the technician is trying to recreate the problem.
But I was hoping that I did something wrong. No idea how long it takes then until it is patched.
I had a similar case before where the timestamp was not transferred. Here the trick was to set a 0 as Value. ISE then makes the current time out of it in the CoA.
But in the meantime I have no more idea and I will wait for the TAC and report here.

[aleksie.sanchez]

Hi StefanSeubert44470

Would you share if this issue was solved with TAC? and how it was solved?

Also, please share the Network Device Template you have working with Extreme Switches,

Thanks,

[asimitch]

Hello Stefan,

The solution to this issue would be to make one minor change to your current Network Device Profile. The only thing you need to do is to change the value for Filter-ID to 0. For some reason the Extreme Switches accept and process that value resulting in a successful CoA-Reauth.

In addition, you will need to change the global Profiler setting to Port Bounce, since a session termination is required for the CoA to work as expected in this scenario for Extreme. This is done under Administration > System > Settings > Profiler > CoA Type.

[StefanSeubert44470]

Hello Asimitch,

if I set port bounce globally in the profiler, this would then also be applied to the Cisco switches, right?
This would cause our IP phones on the Cisco switches to reboot.
Here it would be great if the CoA action could be bound to a network device profile.
We have now found a way to deliberately avoid a scenario that requires a dynamic CoA.
My bigger problem with the Extreme switches currently is that the endpoint status is not correct.
When I connect a device, I have a 50/50 chance that it will get the connected state in the ISE. Then after a few minutes/hours it switches to disconnected status even though the device is active.
Do you have a tip how to set the timers etc. on the Exos switches? Accounting actually works, otherwise I would see no status at all and always get disconnected end devices displayed. But as mentioned above I also have devices that are green after connect, at least for some time.

[Arne Bier]

I believe that ISE won't send a port bounce to an interface, if it detects/learns that that interface has a voice endpoint attached. I have never tested this but it's in the documentation somewhere. That would prevent a port bounce when a workstation is attached to the phone itself.