Solved: CSCvg88945 CoA on Reprofile Still Not Fixed - Page 2

paul · ‎08-09-2018

This bug has gone on for so long and it is key concept that has to work in ISE. If there is a profile change and I have CoA set globally to Reauth or specifically set on the profile to Reauth ISE has to send out a CoA.

I am testing this with 2.4 and it still doesn't work. If things go from unknown to anything that works, but when there is a profile change say from Cisco-Device to Cisco-IP-Phone it doesn't work.

In particular, I have IND integrated with ISE setting custom endpoint attribute tags that allow be to switch SGT tags based on these attributes. Profiling with these attributes is working perfectly. As soon as I change the security tag in IND the profile changes in ISE, but no CoA is sent. If I manually CoA life it good.

You might say well what about the silly exception action work around. That does work for the first flip, but then the profile is statically set and no more profiling can occur for that MAC. So when I switch it back in IND it doesn't reprofile.

Can I get an accurate status of this bug or get it reclassified as not fixed? If the devs need someone to truly test out a fix for them I am willing to do that.

</vent mode>

paul · ‎08-27-2018

The subscriber:reauthenticate-type=last was not an issue like I thought it. I will send you the TAC case after I get it open. I am collecting the support bundle now and putting together a PDF that shows the whole issue.

yvesmorneau · ‎08-31-2018

We run ise 2.3 patch 3 (2.3(0.903)) and we still get the issues.

paul · ‎08-31-2018

CSCvm22838 is the new bug to track this fix. It is not visible yet. Putting as much pressure from lots of angles to finally get this fixed. It is a critical feature in ISE that has been broken far too long.

Justin Walker · ‎09-17-2018

My open TAC case was also linked to CSCvm22838. TAC said 2.4 patch 4 for targeted release for a fix and tentative early October time frame for release.

Justin Walker · ‎10-11-2018

Well, 2.4 patch 4 has been released and no fix was included. Not only that, a couple of the TAC cases i have involving the issue have been asked to provide additional evidence of issues with the CoA after reprofile.

The easiest way I've been able to reproduce it (maybe its the only method doing it), is to set an IP Address condition in a new profile. The delay in the IP Address information being sent to ISE is just enough that a CoA action has to take place for the device to be authorized. The profile will match correctly, but the CoA is never sent.

Between the cases i have opened, the following bugs have been referenced... all terminated:

CSCvg88945
CSCvm22838
CSCvk25516

Anyone else having these issues, or made any progress with TAC?

paul · ‎10-11-2018

Yes, the using IP address in a profile is a classic problem with the CoA on reprofile not working. The issue is worse when you use a profile because when ISE receives a RADIUS stop message it will remove the IP address from the endpoint causing it to reprofile. So the next time it connects it will hit the wrong rule and be stranded again.

I have a very high profile case on this. We are pushing the Devs from the Cisco sales side as well.

Justin Walker · ‎10-11-2018

I've had a couple of clients now that have upgraded to 2.4 from 2.1/2.2 installs. Each of them has hit this issue in some varying degree.

Thank you for confirming that this is still relevant and that you have a case open as well. TAC said it was going to be fixed, but then came back and said the Devs cannot replicate the issue. I was starting to second guess myself, because I found it extremely easy to replicate in a lab with the IP address condition.

Thank you Paul for your reply.

Jason Kunst · ‎10-11-2018

Please the more people on the case that can replicate and provide data then the quicker to fix.

If you can easily reproduce then please escalate the issue for further visibility

yvesmorneau · ‎10-11-2018

Hi,

You should follow the bug CSCvm22838. We could confirm this is not patch but worst at 2.3 patch 5. We actually use a rehauthentication as workaround like suggested in the bug. So we have an open case open with TAC.

paul · ‎10-11-2018

Manually reauthenticate the device after profiling finishing is not a viable option. This should all happen automatically. We don't need a help desk ticket every time a new piece of equipment shows up that is profiled correctly but because CoA doesn't work it doesn't have access to the network.

yvesmorneau · ‎10-12-2018

Hi Paul,

We didn't do it manually , we know it's not clean and could create side issues. And we hopfully wait the return of COA. But during this time network must operate !

What we do as workaround:
1.NAD configured to accept timer of rehautentication by av-pair.

2.An autorisation Policy of profilling for all unknow device or transitive profilling categorie (ex: Cisco-device). With this Policy we send the av-pair for rehautentication with an agressive timer and a Vlan were we could profile and the device didn't get ip address.

3.At the rehautenttication the device must be profiled, so the autorisation policy should be the good one. In this policy we send av-pair for rehautentication with a much longuer time and good network access.

configuration in switch port:

authentication periodic !active rehaute periodicaly
authentication timer reauthenticate server !use the radius av-pair value in the radius response to set periodic rehaut time.

In Policy authorization result:

Session-Timeout = {time in second} !will rehaut with the asked time
Termination-Action = RADIUS-Request !will maintain connectivity during the rehaut process

I hope this could help,

shamax_1983 · ‎11-04-2018

Thanks all for the information about this ongoing bug.

I can also confirm that this is not working on ISE 2.3-Patch4. TAC case opened 685425611

Really hope that this will get fixed permanently with Patch5.

Can't believe Cisco let this drag for so long without providing a proper fix - Such key functionality within ISE.

paul · ‎11-13-2018

Update on this. I am testing a Hotfix provided by the Devs and my testing so far looks good. I have been able to move a device around via reprofiling and CoA are sent every time. Hopefully we will get this fixed once and for all. No word yet on when the official fix will be put into a patch.

shamax_1983 · ‎11-15-2018

Thanks for the update Paul.

umahar · ‎03-01-2019

Seems like this bug is still not fixed in 2.4 p6 according to release nots.

Any recent updates ?

https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/release_notes/b_ise_24_rn.html#id_98767