topic Re: Reporting on Current Active Sessions Guidance in Network Access Control

Reporting on Current Active Sessions Guidance

Arne Bier — Tue, 07 Jun 2022 01:23:36 GMT

Hello,

I am trying to understand why ISE reports different results when I ask it how many "Active Sessions" there are for a particular type of authorized device. To help me (and ISE) to filter/report on the exact Authorization Policy Rule that I am interested in, I have given them unique names like Employee_DOT1X_LowImpact, and BYOD_DOT1X_LowImpact (just to name a few). I have also given the Result Profiles unique names (even though their results are always the same) purely to assist me (and ISE) in producing reports.

The ISE Dashboard reports a total number of Active Endpoints - when I click on the hyperlink it opens a nice table that I can apply my search criteria on (e.g. how many BYOD users in low impact mode are active right now). But what I find is that the results in this search are not the same as when I filter in Operations > Reports > Endpoints and Users > Current Active Sessions

Lastly, if I perform my search again using Live Sessions, I get a different answer altogether.

How does ISE define an Active Session? Does it mean that a RADIUS Accounting Start/Update had to have been received within the last 24 hours to be considered 'Active' in Live Sessions and Operations Report?

The Dashboard click-down method (filtered on 'Connected') seems to be the only reliable method because it doesn't seem to care about the Interim accounting in last 24 hours (that's the only explanation I have). My switches send a Interim update every 48 hours (Cisco recommendation).

I have been considering lowering that Interim update to 23 hours to see if that improves (with around 15000 wired endpoints this should not cause too much accounting overhead).

thoughts welcome 🙂

Re: Reporting on Current Active Sessions Guidance

Marcelo Morais — Tue, 07 Jun 2022 04:58:29 GMT

Hi @Arne Bier ,

my thoughts ...

All Endpoints at Home > Active Endpoints Dashboard has the Authentication Status as Connected, but some of then has "No Active Sessions" (I tried a CoA Session Reauth😞

The Operations > Reports > Reports > Endpoints and Users > Current Active Sessions has the following Session Status:

. Authenticated
ISE accepted the Session, but did not receive RADIUS Accounting Start. If no Accounting Start message is received, the Session will be removed after 1 hour.
. Started
ISE received RADIUS Accounting Start. ISE requires Interim Accounting message to be sent within 5 days, if not the Session will be removed.
. Postured
The Endpoint has been Posture checked and Compliant using the AnyConnect Posture Module.

The Current Active Sessions with Session Status of Started or Postured have more value for me then Authenticated (that could be removed after 1 hour) and since the Active Endpoints Dashboard has Endpoints without a Session, I prefer to "trust" the Current Active Sessions [Started | Posture].

Regards

Re: Reporting on Current Active Sessions Guidance

Arne Bier — Tue, 07 Jun 2022 05:45:33 GMT

Thanks Marcelo - one benefit of fishing out all the "Authenticated" sessions is that those are potentially from switches where RADIUS Accounting is not configured (or misconfigured). Having said that, it's hard to tell because the RADIUS Accounting UDP packets could also be dropped/lost. But it's worthy of some focus if there are many of these.

Also, you highlighted that ISE refers to Active Endpoints and other times, Active Sessions. Are you saying that an Active Endpoint is the more general term of any Endpoint that has passed authentication, but that Active Sessions are those, which also send RADIUS Accounting? In an ideal world all Active Endpoints should also have an Active Session.

Re: Reporting on Current Active Sessions Guidance

Marcelo Morais — Tue, 07 Jun 2022 15:14:44 GMT

Hi @Arne Bier ,

when you said " ... But it's worthy of some focus if there are many of these ("Authenticated") ... ", totally agree, Authenticated as an indication/possibility of an issue, but (for me) not as a "real" Active Session (because at that point there is no Accounting Start).

when you said " ... Are you saying that an Active Endpoint is the more general term of any Endpoint that has passed authentication, but that Active Sessions are those, which also send RADIUS Accounting? ... ", the straight answer is yes, whenever I checked the Active Endpoints Dashboard there is not only Endpoints with Active Sessions, but also Endpoints without Active Sessions.

Regards

Re: Reporting on Current Active Sessions Guidance

Arne Bier — Wed, 08 Jun 2022 20:45:11 GMT

As for the ISE Reports ... those that say "current Active sessions" ... that list does not seem to reflect the real situation. What are your views on fixing that? Is my understanding correct that ISE considers only endpoints active if it has seen an accounting in last 24 hours? So if the switch is sending the accounting interims every 48 hours, then you see (or not see) endpoints, depending on what time you click on these reports. Or click on the main Live Sessions menu option.

I am considering returning a session-timeout of 65565 seconds (because there are older IOS-XE versions in play ... I can't use any larger value). But this value should re-auth the wired endpoints more regularly (18 hours) and I thought it might improve the "live/active" sessions visibility in ISE. Does that make sense?

Re: Reporting on Current Active Sessions Guidance

Marcelo Morais — Tue, 14 Jun 2022 22:56:35 GMT

Hi @Arne Bier ,

the Operations > Reports > Reports > Endpoints and Users > Current Active Sessions is more accurate than Home > Active Endpoints Dashboard, the 1st gets the info from MnT (License consumption is based on the MnT data), the 2nd from Context Visibility (PAN data).

Regards

Re: Reporting on Current Active Sessions Guidance

ajc — Mon, 17 Mar 2025 17:51:41 GMT

Hi @Arne Bier and @Marcelo Morais , I am replying to this post because this ACTIVE ENDPOINTS / ACTIVE SESSION is quite confusing for me:

From Dashboard -- > Active Endpoints (screenshot below), if I click on that number then a LIVE SESSIONS browser opens automatically.

So my question is: Does that number of 149494 ACTIVE ENDPOINTS mean that we have 149494 LIVE SESSIONS as well, each one of those LIVE SESSIONS falling into the ONE of the next categories: (terminated/authenticated/authorized/started/authenticating/postured?

WHERE the most important SESSION STATUS would be = STARTED because a radius accounting start was sent, right?

Re: Reporting on Current Active Sessions Guidance

Arne Bier — Mon, 17 Mar 2025 20:42:50 GMT

I am still none the wiser on this topic. it should not be this complicated to understand, and we should not have to reverse engineer how ISE works. My current opinion is that there is a mixture of factors that is causing a discrepancy in the numbers seen:

bugs in ISE (I experienced this recently where the endpoint was reset on switch, and ISE Context Visibility showed the endpoint as green/Active for around 1 second and then was grey again. The switch session was up and accounting work (proved with tcpdump). I have to conclude that ISE has "issues"
bugs in the IOS. Some older IOS versions don't count all the types of RADIUS packets sent and received - most notably, the Interim Updates (often shown as "0" in the "show aaa servers" output) - I have interims configured of course (standard DNAC provisioned device) and I am pretty sure they were captured in the tcpdump on ISE. However, I didn't see/capture what happens after 2880 minutes (the number of minutes until the next gratuitous interim update)

One day when I get a few minutes spare, I might do some things

Test all this in a lab with only active 1 endpoint and then test the theory by laser focusing on how ISE behaves
run a python script across all the production switches to capture the output of "show active sessions | Count Auth" and then tally the numbers - compare that with what ISE reports as "Active Sessions" - then see how large the margin of error is. The trick is to write a threaded python script that can spawn more than one SSH simultaneously, to avoid this process taking too long - especially with large numbers of switches.