cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
330
Views
1
Helpful
3
Replies

ISE - endpoints persisting in database after deletion

JaseNL
Level 1
Level 1

I have a lab ISE server which I am using to develop API clients. Originally that server had a large number of endpoints configured which I deleted using the web UI when I started using it.

I have just been working on code to replicate the web UI Export Endpoints function (exporting to a file named profiler_endpoints.csv) which requires the downloading of all configured endpoints. This is done on the OpenAPI side by calling the endpoint method without any ID or MAC address, and on the ERS side by first retrieving the endpoint IDs using the endpoint method without any ID, and then retrieving the endpoint data itself by iterating through each endpoint/<id>

Using my client code to create, update and delete endpoints, I can validate that these processes have been successful using the web UI (including the export endpoints function). But if I use the above method to retrieve data for all endpoints, I seem to get the full complement of endpoints which I deleted when I first started working with the server.

The output pagination code is working fine for both APIs, and looking at what gets returned there are no duplicate MAC addresses.

Are endpoints kept in the database after deletion, and do I need to filter these out in my API requests?

Or is this some kind of database corruption issue? The server has been rebooted at least once since I deleted all those endpoints, and it seems they're still there.

Cisco ISE version is 3.2.0.401

Server version is 3.2.0.542 patch 3,5,6

Thanks in advance

1 Accepted Solution

Accepted Solutions

ccieexpert
Spotlight
Spotlight

yes it was gone from the ERS api...

you're facing some sort of a bug likely a result of some stress testing..

the important thing is you need to be able to reproduce it for TAC to move forward..

maybe you want to start from scratch on a new ISE deployment and also take vm snapshots, so you can revert back... and try to add 100 and delete 100 to see if you can at what point  you see a anamoly..

** Please rate as helpful if this was useful**

View solution in original post

3 Replies 3

ccieexpert
Spotlight
Spotlight

i did the same test with 3.3 and dont see any issues.. i am using ERS

i first had the endpoint and api showed it

"id": "ce5e63f0-4c28-11ef-8070-4eb494f82f6b",
"name": "7C:78:B2:33:08:3E",

after deleting from the gui, the search showed zero hits

ccieexpert_0-1722665937965.png

double check from the gui that the endpoint is really deleted..

 

JaseNL
Level 1
Level 1

Thanks, you're a version later than me I notice.

After deleting from the web UI did you check via the ERS API that the endpoint had really gone? I wouldn't really expect with single endpoint operations that you'd have issues. I've been testing performance with large numbers of endpoints (create, update and delete using the bulk APIs and also concurrent single requests) so I think it's some kind of database corruption issue. It has all the hallmarks of user error (me), but I've spent the past week trying to figure out what silly and obvious (with hindsight) thing I've missed and the fact remains that according to the web UI there are no endpoints, yet the ERS and OpenAPI APIs both return many endpoints.

I've also been getting SQL errors with OpenAPI bulk create operations (https://community.cisco.com/t5/network-access-control/sql-errors-with-ise-open-api-bulk-create/td-p/5148395) - don't know if they're connected but it looks like a TAC case might be the best option ...

ccieexpert
Spotlight
Spotlight

yes it was gone from the ERS api...

you're facing some sort of a bug likely a result of some stress testing..

the important thing is you need to be able to reproduce it for TAC to move forward..

maybe you want to start from scratch on a new ISE deployment and also take vm snapshots, so you can revert back... and try to add 100 and delete 100 to see if you can at what point  you see a anamoly..

** Please rate as helpful if this was useful**