IP device tracking not reflecting correct IP address in live logs

[dgaikwad]

Hi Experts,

Setup:
ISE 2.7 with switch running IOS 15.x
Posture checks with VLAN change from limited access to full access for compliant endpoints
IP device tracking commands are enabled on switch

Issue:
ISE live logs show different IP address compared to the IP address assigned to endpoint

Description:
When the endpoint connects for the first time, and comes online on an interface, live logs show the IP address from production VLAN in live logs (Whereas it should show the IP address from the limited access VLAN)
After the posture is completed, a VLAN change happens and the IP address from full access VLAN is assigned to the endpoint
While during this entire process the endpoint shows the correct IP address, but live logs reflects incorrect IP address...
That is when in posture, it shows IP address that was previously assigned in full access and when posture completes IP address from limited access VLAN...

Troubleshooting:
Modified device tracking delay multiple times, and increased/decreased tracking delay many times, but there has been no change. And this happens to every endpoint that I connect.

Has anyone faced this similar issue before and solved? Or if pointers much appreciated.

Thank you,

[Massimo Baschieri]

I observed the exact same issue on ise 2.6, after a vlan change live logs not always reflects the ip address change, this happens on 802.1x authenticated hosts as well as mab hosts.

Time ago I spent some time troubleshooting the issue and I concluded that the problem is ise, since the switch was correctly sending the accounting message with the ip change.

I wanted to open a tac case on this, but since for now it's only a cosmetic issue I never took the time.

However for those who use features like trustsec it would be a mess

[dgaikwad]

Did you follow any troubleshooting steps to get to bottom of this issue?

And when you say that this will affect while using TrustSec, what are the probable issues that will be hit with this happening?

[Massimo Baschieri]

It was time ago, but I think I analyzed ise-psc log.

I thinking about sxp, where access devices download ip/sgt mapping from ise

[Aref Alsouqi]

Interesting! I've never seen this behaviour before. However, I don't think the issue would be related to the device tracking. Device tracking mainly relies on ARP to build up the MAC-to-IP database. So, if the device tracking receives an ARP reply from the connected client with that wrong IP, or if ISE receives that wrong IP through RADIUS accounting messages, I would think maybe there is something on the client side that is triggering this behaviour.

[dgaikwad]

Yes, the issue might not be from switch or ISE, but then this is going to bother a lot afterwards. Is there anything that I could check from the client end to further dive deeper in this issue?
And the other thing is that this issue is not observed on our wireless infrastructure, so it gets pretty interesting for sure...

[thomas]

There are 3 parts to the solution: endpoint <==> switch <==> ISE

So you need to verify each part and see where it's breaking down.

If it only happens with the switch, most likely a switch config issue or a bug.

[roncrawford82]

Has anyone found a resolution to this issue? I just upgraded from ISE 2.2 to 2.7 and now experiencing same issue. The IP address the ISE server show associated to the client is the same on many clients. 

[thomas]

There are 3 parts to the solution: endpoint <==> switch <==> ISE

So you need to verify each part and see where it's breaking down.

If it only happens with the switch, most likely a switch config issue or a bug.

[thomas]

There are 3 parts to the solution: endpoint <==> switch <==> ISE

So you need to verify each part and see where it's breaking down.

If it only happens with the switch, most likely a switch config issue or a bug.

[dgaikwad · Accepted solution]

As off there is no resolution seen, but a TAC case has been logged to troubleshoot it further.

[Jarvis IT]

We have been having the same issue since upgrading to 2.7 some time ago, maybe even since a late 2.4 patch. Pretty certain this problem has come and gone a number of times.

Windows clients on the WLC (we use 802.1x peap eap tls) do not have this issue, only Windows clients on our WS-C2960X-48FPS-L (c2960x-universalk9-mz.152-4.E8.bin) switch using 802.1x peap eap tls seem to have the issue.

I have raised TAC cases, supplied wireshark logs and lot of diag data.

At one stage I thought it was QoS dropping the packets, certainly I was wrong. If you sign out of windows and back in the IP updates without issue. A reboot simply puts you back in the same situation, only a sign out/sign back in seems to update the IP correctly.

I have played with the Reauthentication option under Authorization Policy, the default is like 1800 seconds, but it does work to update the IP information.