cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2857
Views
0
Helpful
4
Replies

Accounting Stop not Terminate Session on ISE

Nicholas DiNofrio
Cisco Employee
Cisco Employee

On a Meraki AP (MR42) running MR.25.11 firmware that has been configured in VPN: Tunnel Mode to send all traffic to an Meraki MX appliance/concentrator which authenticates to ISE 2.3 patch 5.


We are seeing after ISE receives an Accounting-Stop (Terminate-Cause=Lost Carrier) the session does not get terminated in ISE and thus session (approx. 420ms apart) count/license consumption keeps increasing under the same session-id.   We also see Accounting Stop then immediately follows an Accounting Start, visible in the prrt-management.log in the same second, which is occurring before the Accounting Stop appears in the collector.log indicating received by the ISE MNT node. Once we can get this issue resolved then we are quite sure license consumption will normalize because session count always matches exactly the base license consumption count during this non-working scenario.


Also in the collector.log we see "cisco-av-pair=SkipSessionRemoval=true" during the non-working scenario.   Within a packet capture we do not see the attribute "nas-update=true".  However, suspect ISE is not able to process the first accounting request in time and by the time accounting requests are logged on the collector.log the ISE MNT has both an Accounting Stop and Accounting Start.


When we remove a session(s) on ISE itself through the use of API we do see the license count also being decremented accordingly and currently don't believe the active sessions on ISE are stale.


There have been reports the endpoint may be changing to different AP's during troubleshooting, we then started looking into if the client is roaming to another AP. Looked into 802.11r but found was not available while in VPN tunneled mode and not seeing the NAD changing but do see the called-station-id changing at times for the same session, however, are getting an unknown attribute that seems to be a value representing an Access Point -- which is also see changing.


At this time have the following questions that would like to seek assistance on:

 

* While in VPN tunneled mode (all traffic), if client should roam to a different AP, then would we should see Called-Station-ID changing even though the Meraki MX appliance would be handling all authentications?

 

* How can we find out what is causing Meraki to send first an Accounting Stop followed by an Accounting Start in the same second?   Under this scenario does this explain why ISE does not clear the session?

 

* Under which scenarios will cause the ISE PSN node to send "cisco-av-pair=SkipSessionRemoval=true" to the ISE MNT node so the radius session does not get removed in ISE?

 

* Any other advice/feedback that may find useful to troubleshoot this issue?

4 Replies 4

Timothy Abbott
Cisco Employee
Cisco Employee

Hi,

 

For the first two questions, you will need to reach out to the Meraki team to understand why the MR42 is behaving in that manner.  Based on what I've read, cisco-av-pair=SkipSessionRemoval=true is sent from the NAD and does not originate from the PSN.

 

Regards,

-Tim

Thank you Timothy for your feedback and guidance.  Always appreciate times to ensure I have the correct understanding.

 

I went back and looked at the prrt logs from the ISE Support Bundle and sure enough found the "cisco-av-pair=SkipSessionRemoval=true" attribute.   Not sure what happened but at first did not see that attribute in the prrt logs, only in the collector.log -- hence why thought was being sent from ISE PSN to ISE MNT.

 

We've already brought in Meraki but they are still working on their analysis at this time, just wanted to be proactive and try to get this figured out at the same time.   Will post back to this thread once have confirmed information from Meraki, so that is helpful for other people.

Hi Nicholas, even though this is an old post, I am interested on the resolution of your situation. thanks

hslai
Cisco Employee
Cisco Employee

@ajc  It might be due to CSCvo86117

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: