Per-Profile CoA not worked

[LenarFA]

Hi, looking for help with configuration per-profile COA in ISE:

New connected "ip-phone" is profiled as IP-Phone, but CoA not worked?

On the switch side, most likely everything is configured correctly, since if I send CoA from ISE > Live Sessions it worked.

Probably I missed something or did not understand from the side of ISE Configuration?

[Mohamed Alhenawy]

hi @LenarFA 

Review the authorization policy in Cisco ISE that matches the IP Phone device profile. Ensure that the policy includes the necessary CoA attributes and defines the appropriate CoA actions. For per-profile CoA, the authorization policy should have the correct authorization profile assigned with the desired CoA actions , also Verify the CoA configuration in Cisco ISE. Ensure that CoA is enabled and properly configured in the ISE administration settings. Check that the CoA port, key, and timeout values are correctly set. Also, verify that the correct CoA settings are configured on the network devices, such as the switch, to accept and process CoA requests from ISE.

[LenarFA]

Thank you for reply, checked everything seems to all right?

If I enable globally CoA Reauth (Work Centers > Profiler > Settings) everything works as expected, ISE send CoA and port is reauthenticate. If I disable CoA globally - No CoA, per-profile CoA nor worked. May be some debug info from ISE would be helpful?

[hslai]

> ... If I disable CoA globally - No CoA, per-profile CoA nor worked. ...

This is expected. The global option acts as a kill switch when set to No CoA. Thus, to allow per-profiler-policy CoA, please set it to re-auth or port-bounce.

[LenarFA]

Hi, hslai,

if I understand you correctly, then we have several cases:
1) if Global CoA are turned on to "Reauth", and per-profile CoA for profile IP-Phone are turned on to "Reauth"
- all endpoints that have changed own profile from "unknown" to "known" will recive a CoA via Global Exception "FirstTimeProfile", including endpoints that have changed own profile from "unknown" to "IP-Phone"
- all endpoints that have changed own profile from "known" to "IP-Phone" will recive a CoA via per-profile CoA for profile IP-Phone
2) if Global CoA are turned on "no CoA", and per-profile CoA for profile IP-Phone are turned on to Reauth
- nothing will happen

That is, there is no option if I want to enable CoA for only this way "unknown/known" to "IP-Phone"? I don't want all devices, that have changed own profile from "unknown" to "known" will recive a CoA.

And, I did not quite understand the purpose of this Global Exception "AuthorizationChange", could you explain, please?

[hslai]

@LenarFA :

If an endpoint changed from Profiler-policy-A to Profiler-policy-B, and if this results in matching a different authorization policy rule, then it will trigger CoA. If matching the same authorization policy rule, then no CoA.

[Aref Alsouqi]

@hslai apart from the authorization rules match, wouldn't the CoA still work anyway? if we think about ISE profiling process, shouldn't changing the endpoint from being unkown to something trigger the CoA? I thought that would trigger it even if you don't have any authorization rule configured yet.

[hslai]

@Aref Alsouqi I focused on Global Exception "AuthorizationChange".

REF: Change of Authorization (CoA)

[Aref Alsouqi]

If the phones get profield correctly then I would say the profiler policy CoA would have worked. First time the phone connects to the network it would be classified as unknown device from ISE perspective, this state will remain as is until that phone is matching the right profiler policy. The fact that you see it as an IP-Phone it would suggest that that phone moved from being an unknown device to an IP-Phone. This state change happens when the phone has been reauthenticated after it was showing as an unknown device and this reauthentication process would have been triggered via the profiler policy CoA. If the profiler policy CoA wouldn't have worked, you wouldn't see that phone profiled as an IP-Phone, in that case you would still see it as an unknown device.

[LenarFA]

Hi, let me explain this issue step by step:

"First time the phone connects to the network it would be classified as unknown device from ISE perspective, this state will remain as is until that phone is matching the right profiler policy. The fact that you see it as an IP-Phone it would suggest that that phone moved from being an unknown device to an IP-Phone"

It only mean that profiling is working - nothing else, yes phone profiled as IP-Phone by device sensor, but CoA not sending by ISE and phone stay on it initial session (for unknown device rule) until shut/no shut or session timer expired. It is behavior via per-profile CoA - profiling working, CoA - not.

If I turn global CoA, phone profiled as IP-Phone by device sensor, CoA is sending by ISE and phone reauthenticated to new session (rule for IP_Phone).

[Aref Alsouqi]

I slightly disagree on a couple things. Device sensor would feed ISE with the LLDP details into RADIUS packets that will match the IP-Phone profiler policy. As a result, the phone will move from being an unknown device to a known device. This last bit would happen via the CoA, when ISE triggers the reauthentication via CoA you will then see that phone profiled as an IP-Phone. Did you actually run some packet capture on the switch or ISE to see if ISE actually sends any CoA traffic that would have been triggered through the profiler policy?

[LenarFA]

Maybe I didn't explain exactly, English is not my native language...

Ok, ok, when I disable global CoA (it is by default) and disable CoA in profile (it is by default) how profiling work?

[Aref Alsouqi]

Apologies for not being clear in my last post. As per my knowledge, if the global CoA and the profiler policy CoA are both disabled, I wouldn't expect the phone to move from unknown to IP-Phone because when ISE sees that phone for the first time it would see it as an unkown device and then after a CoA is triggered the phone will complete its profiling process in which will move to its profiled category. The profiling feeds will just help ISE to know more about that device and try to match those attribues received by the feeders to a profiler policy. If no match the device will remain classified as unknown.