Meraki API timeout after 120 seconds

RaphaelL
Kind of a big deal
Kind of a big deal

Meraki API timeout after 120 seconds

Hi ,


I have been experimenting lots of timeouts with api.meraki.com recently. 

 

I have tried with both my personal PC on my home network AND from my work PC from corporate network.

 

I was able to take a pcap of what is happening :

 

RaphaelL_0-1633114134564.png

 

On packet 6448 Meraki ACK my api call but then 120 seconds later Meraki tears the connection due to inactivity... but I was waiting on them to retrieve me the info... 

 

Python requests module returns : requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

 

The API call made seems to always be : '{0}/networks/{1}/devices'.format(str(base_url_v1), str(networkID)). It's never the same network but they are in the same Org ( Org isnt specified here )

 

I'm not using the SDK , I'm using a simple function with requests. 

 

def getNetworkDevice(apikey, networkID):
    geturl = '{0}/networks/{1}/devices'.format(str(base_url_v1), str(networkID))
    dashboard = requests.get(geturl, headers=headers,timeout=600)
    result = __returnhandler(dashboard.status_code, dashboard.text)
    return result

Has anyone ever seen those kind of issue ? I'm about to open a ticket. I know I could simply use a smaller timeout than Meraki and retry until I get a response , but this is only a temp fix. 

7 REPLIES 7
PhilipDAth
Kind of a big deal
Kind of a big deal

I don't think I am understanding correctly.

 

 

There is no way that a call to "{0}/networks/{1}/devices" would take 2 minutes to respond.  I haven't used the REST API in a long term (I mostly used the Python SDK), and I never get timeouts.  Never.

 

Is the issue that you make the API call successfully, and then sometime later you are getting this exception?

 

Have you tried the sample code that the developer website creates?

https://developer.cisco.com/meraki/api-v1/#!get-network-devices 

 

import requests

url = "https://api.meraki.com/api/v1/networks/{networkId}/devices"

payload = None

headers = {
    "Content-Type": "application/json",
    "Accept": "application/json",
    "X-Cisco-Meraki-API-Key": "xxx"
}

response = requests.request('GET', url, headers=headers, data = payload)

print(response.text.encode('utf8'))

 

PhilipDAth_0-1633125113641.png

 

RaphaelL
Kind of a big deal
Kind of a big deal

I know it doesn't make sense that the query would take 2 minutes to respond but the pcap is not lying. Meraki acknoledges the API Call but never returns anything then after 120 seconds closes the session.

 

I have used lots and lots of differents calls but it seems to be only affecting this one.

 

Sometimes it will time out after 60 networks , sometimes more. But I can reproduce the issue all the time.

 

My code is very similar to the snippet on the developer website.

 

I have retried the same network and got it to work : 

 

RaphaelL_0-1633126548026.png

350 - Meraki ACK the API request

370 - Sends the Data back

371,375,376 TCP Session ending. Client caused the session ending.

PhilipDAth
Kind of a big deal
Kind of a big deal

Have you got an org on another shard you can test with?

 

Maybe that one shard has an issue.

Alisdair85
Getting noticed

Hi @RaphaelL there is a known issue with Meraki Development/Engineering with api.meraki.com I have had a case open since July for the same timeout behaviour, their recommended workaround for the moment is to use the node/shard FQDN for that customer / Org i.e n<123>.meraki.com we have coded this into all out apps and not had any performance challenges.

 

Cheers

 

Ali 

RaphaelL
Kind of a big deal
Kind of a big deal

Ohhhh !  

 

I will try this right away

RaphaelL
Kind of a big deal
Kind of a big deal

Using the shard URL instead of using "api.meraki.com" solves the issue ! 

 

I will open a ticket and assign a priority on it.

 

Thanks !!

No problem at all, happy to help, yes makes sense to raise a case too

Get notified when there are additional replies to this discussion.