For my lab, I have setup 2 PSNs in my ISE cluster, I found if I configured AAA accounting for dot1x and network authorization on switch (by using the command "aaa accounting dot1x default start-stop group radius" and "aaa accounting network default start-stop group radius"), the AAA traffic and posture traffic from client will be sent to same PSN. But if I delete the command of "aaa accounting", the AAA traffice from client and posture traffic from client will be sent to different PSN, in this case, if AAA traffice was sent to PSN1 but posture traffic was sent to PSN2, after posture status changing, switch will not accept the COA from PSN2.
I would like to know the aaa accounting work flow and why the aaa accounting will affect to AAA traffic and posture traffic.
Thanks a lot
I am not sure what Accounting and Posture have in common but RADIUS Accounting is always associated with an active Session on the NAS. The NAS will send an Accounting Start when the session starts, and a Stop when the session terminates (e.g. session timeout or session killed by operator). RADIUS Accounting Interim-Updates are sent (if configured) by the NAS at an interval period to inform RADIUS server of the status of the session.
When the RADIUS server sends the CoA to change the session authorization, then it must send the CoA to the NAS that is handling that session. NAS will send a CoA-ACK back. In the case of ISE, the PSN that sends the CoA must also receive the CoA-ACK. If this is not the case, then there is a problem at a fundamental layer (IP routing, or load balancer, firewall, etc.)
When you click on the ISE GUI Context Visibility to change the Session's state (e.g. Re-Auth, or Port Bounce) then ISE does something funky under the hood and the CoA is sent by the MnT to the PSN or something along those lines - I never understood why, but in the end, the NAS receives that CoA from the PSN's source IP address. The NAS must send the ACK to that same PSN. When PSN receives that ACK then it knows the CoA was successful.
Run a tcpdump on the PSN to see this in action.
I think we are looking at the wrong issue here. The issue could be all together with the posture redirect failing.
since you have the accounting configured, even when the redirect fails, the correct PSN fqdn is returned to the client and posture succeeds which fails otherwise without accounting.
you will have to collect dart files on endpoint and debug on ISE to troubleshoot the issue. please also raise a TAC case