ISE profiling issues when using IP address in profiling criteria

[paul]

I have observed an issue that I wanted to run by the community to see if this is an known issue.

I have a few clients where some of their profiles include IP address matching, either regular expressions or starts with.  ISE will correctly profile them and they hit the desired MAB rules.

Periodically though we will see the device show up in the Live Logs not hitting that profile but if we look in Context Visibility it will have the correct profile.    It may go back to Microsoft Workstation briefly then go back to the correct profile.  All my custom profiles have higher minimum certainty factors than any of the Cisco built in profiles so it should never fall back unless profiling data is lost.

My current theory is that during reauthentication or a power cycle the RADIUS transaction doesn't include the IP address of the device initially so ISE removes that attribute causing it to get reprofiled.  Then once it learns the IP it will get profiled correctly.   Because of the various CoA bugs the CoA isn't happening and the device is stuck in my catch all rule.  If we manually do a CoA then it hits the correct rule.

Or does ISE timeout an learned IP after a period of time?  I am only doing accounting with "newinfo" so if the device is on the network for a long period of time there won't be an update.

Anyone seen anything like this? 

The profile change reporting doesn't show anything, but clearly the live log shows the profile change.

For now I am probably going to put in a Exception action to ensure the CoA happens so the device is not stuck.

[Craig Hyps · Accepted solution]

ISE will clear the IP address for an endpoint on RADIUS Accounting Stop.  This was implemented to prevent profile data associated with a new device (assigned the same DHCP address) from being incorrectly applied to previously connected device.  For this reason, it may cause issues if profile itself is predicated on IP address.  It may make sense for logic to only apply to clients where DHCP also collected for endpoint versus endpoints that may have static IPs. 

For specific issues with CoA, or profile changes not displaying consistently in Context Visibility or Profile Change report, be sure to open case and determine if defect needs to be filed. 

Craig

[paul]

Craig,

Thanks for the information and confirming what I was thinking.

The main bug that was supposed to be fixed in 2.3 patch 3 is CSCvg88945. Even if the device does go to Microsoft Workstation and comes back to the correct profile a CoA should be sent. I have the CoA for Reauth set globally and on the profile itself. That has been broken since 2.3 came out. I still don’t see it working correctly which makes me think the bug is not really fixed.

I will probably just do exception actions for any profiles that have IP used in the profiling.

[Justin Walker]

I've had a couple of clients recently update from 2.1/2.2 to 2.4 and this issue has popped up.  Each of them was using some method external to ISE to manage DHCP reservations, so profiling was built with the IP Address condition to look for a device within a certain range. 

The connecting device initially hits the default authz rule due to a generic profile match. After the IP address is captured and sent along, ISE does reprofile the device to match the custom profile.  You can see the profile match in Context Explorer and Live Sessions, but no CoA is ever sent to reauthorize the device.   If you manually send a reauth to the device from live sessions, it receives the proper authorization profile and the device is permitted until the next time it disconnects from the network. 

One of the TAC cases open was referenced the the following BugID: CSCvk25516  

The work around is just to not use IP Address in profiling.  If that's the correct answer to this issue, then IP address should be removed as a profiling condition moving forward.  At very least it should be mentioned in an upgrade document to check for profiles dependent on IP Address condition.