Cisco Prime 3.3 API call to force sync device

[Craig Tomkow]

Hello,

I am looking to force a sync of a device via Cisco Prime Infrastructure 3.3 API. I am referencing the following API documentation below.

Prime Infrastructure API Documentation | Cisco Prime Infrastructure API

Basically, I am trying to POST some JSON which specifies the IP address of the device I want to force a sync of. I get a status code of 200, however, I don't see Prime sync'ing the device. I will say, I have been making GET requests for device information easily enough.

I am using Python with the 'requests' library to manage the HTTPS request. The library also handles the JSON serialization from a python dictionary.

Please see the code snippet below.

url = "https://Prime_Server_IP/webacs/api/v3/op/devices/syncDevices.json"
payload = { 'syncDevicesDTO' : { 'devices' : { 'device' : [ { 'address' : 'switch_IP' } ] } } }


req = requests.post(url, verify=False, auth=(username, password), json=payload)

Any help would be appreciated.
Thanks.

[Spencer Zier · Accepted solution]

Thanks for reaching out

It looks like you're sending the request correctly, and the fact that you didn't get a 4xx or 5xx response seems to confirm that.

There are a couple things about sync and the way our inventory management component in Prime Infrastructure works:

1. Sometimes syncs get queued.  This can occur when we already have a lot of traffic going out to the network, or to that device in particular.
2. Some devices sync very quickly.  In Prime Infrastructure, some devices have less "features"; that doesn't necessarily that the device itself doesn't have a lot of features, just that we don't support configuring or monitoring them via Prime Infrastructure.  A good example would be unsupported third party devices, which can sync very quickly because there's not much Prime Infrastructure has to sync.

Perhaps the best way to programmatically verify that the sync occurred is to query /webacs/api/v3/data/Devices?.full=true&ipAddress=switch_ip before and after POSTing the sync.  The collectionTime parameter should change, and you can also check that collectionStatus is COMPLETED and managementStatus is MANAGED_AND_SYNCHRONIZED.  You may happen to catch the sync in progress, in which case collectionStatus will show SYNCHRONIZING and managementStatus will show MANAGED_BUT_SYNCHRONIZING.  Should the collectionStatus and managementStatus not move to COMPLETED and MANAGED_AND_SYNCHRONIZED, respectively, then check the collectionDetail parameter, which provides more details.

If you still find that the sync is not actually occuring, please login to the UI as an admin user, go to Administration > Settings > Logging, and click the download log button shortly after performing the sync request via the API.  The log bundle is usually quite large.  You can reach out to me via email (available to logged in users on my profile) to arrange for secure sharing of the log bundle so that we can help you further

[Craig Tomkow]

Hi Spencer,

Thanks for the reply! I checked the "collectionTime" before and after a sync call (while waiting a bit for any queueing and delays). It did not change, so it seems to not sync correctly against my one switch 3650 stack.

However, I did do more testing and found I COULD force a sync successfully on a switch stack with IOS-XE code 16.3.5b, 3.6.6 and 3.6.3. The switch stack I was working on earlier has code 3.3.3, so this may have something to do with it.

I am working on automating switch state verification after a code upgrade, so the fact that I can't force a sync against older switch code is less important.

I won't bother with going down a rabbit hole for an issue that won't apply soon enough

Thanks again for your help!