MnT API call takes too long

[pabloayalas]

Hello,

I'm working on an integration via MnT API calls where I can provide to end-users the status of their endpoints (if they are getting blocked or allowed by ISE) as well as some location (port and switch).

I have a distributed deployment running version 2.7 patch 4 and I'm using the session API calls towards the monitor node (which is running on a SNS-3655 hardware). Every time that I trigger the API call it takes ~ 3.5 minutes to get the response, is this ok? It takes a lot of time to pull out information from the endpoints. Also, I would like to know if there is any way where I can just get certain information from the session, I tried to use a filter but had no luck.

This is the current call that I'm using to get endpoint session information:

https://MnT_node/admin/API/mnt/Session/MACAddress/xx:xx:xx:xx:xx:xx 

If I want to run some filter then I would use this query:

https://MnT_node/admin/API/mnt/Session/MACAddress/xx:xx:xx:xx:xx:xx?filter=EQ.selected_azn_profiles  

But I still get the same output with the same time (~3.5 minutes).

Finally I also would like to know if this is impactful to the monitor node, I don't expect 100 queries per minute but I don't want to open the gates to everyone if this might impact the reporting capabilities for the monitoring nodes.

Thanks 

[Mike.Cifelli]

Every time that I trigger the API call it takes ~ 3.5 minutes to get the response, is this ok?

-I personally have never seen this long of a delay when consuming MNT APIs.  If possible, I would work with TAC on this one.  FYSA here are some filters that may be useful.  Note:  I think not all APIs support each one; pretty sure it varies; check documentation:

--Cisco ISE REST API filters--

EQ: Equals

NEQ: Not Equals

GT: Greater Than

LT: Less Then

STARTW: Starts With

NSTARTSW: Not Starts With

ENDSW: Ends With

NENDSW: Not Ends With

CONTAINS: Contains

NCONTAINS: Not Contains

Also for reference: ISE ERS API Examples - Cisco Community

[pabloayalas]

Mike,

Thanks for replying. I have used the filters but when I try to get specific information from the database, for example, if I want to get a specific mac address out of all the mac addresses in the system, this is the only place where I get those filters but in the case of the monitoring API's I'm not sure if I can filter only, as a result, specific information, for example:

output from the API Call:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<sessionParameters>

<passed xsi:type="xs:boolean" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">true</passed>

<failed xsi:type="xs:boolean" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">false</failed>

<user_name>HOSTNAME</user_name>

<nas_ip_address>192.168.2.32</nas_ip_address>

<calling_station_id>MAC_ADDRESS</calling_station_id>

<orig_calling_station_id>MAC_ADDRESS</orig_calling_station_id>

<cpmsession_id>SESSION_ID</cpmsession_id>

<destination_ip_address>192.168.100.1</destination_ip_address>

<device_ip_address>192.168.200.100</device_ip_address>

<identity_group>Workstation</identity_group>

<network_device_name>SWITCH</network_device_name>

....

Out of this input I only want to display <calling_station_id> and <device_ip_address> and the rest I can just ignore it.

Thanks 

[Damien Miller · Accepted solution]

I ran the call a number of times on a very busy 2.7p6 deployment. It averages 6 seconds to get the results. I would patch, then open a TAC case if it persists. 

[pabloayalas]

Damien,

Thanks for replying. I'll patch our ISE environment and see if that makes any difference, I'm not sure why this takes a lot of time, it's not consistent, and I might need to wait 3 minutes, sometimes 30 seconds, or less than 10 seconds. I'll investigate more and if needed I'll open a TAC case if needed.

Regards

[pabloayalas · Accepted solution]

Damien, just as FYI I'm hitting a bug (CSCvu33861) and this is causing the problem:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvu33861