- Trying to use the REST API 3.1 guide on Cisco DevNet for the Get Configuration Diff and it doesn't pull up any details on how to use it.
- Here is the link to the API guide, Cisco DevNet: prime-infrastructure - REST API - v3.1 API Reference
[dsampson@mnet-ws-dave ~]$ curl -k "https://user:pass@cpi/webacs/api/v1/op/configArchiveService/configDiff/172.25.232.1"
<?xml version="1.0" ?>
<message>Device not found in system: 172.25.232.1</message>
<exception>com.cisco.ncs.nbi.ops.configArchive.ConfigArchiveException: Device not found in system: 172.25.232.1</exception>
Ensure that the IP that you passed in is the management IP of the device that's known to Prime. Also, if you're using virtual domains, ensure that the device is in the same virtual domain as the API user (querying /webacs/api/v2/data/Devices?.full=true&ipAddress=172.25.232.1 as the same user should verify that).
/webacs/api/v2/data/Devices?.full=true&ipAddress=172.25.232.1 works fine and returns data for the device. I can retrieve multiple configs using the webacs/api/v1/data/ConfigVersions?.full=true&deviceName=startsWith("cob1-oet")';
CPI version 3.1 will all the updates with the exception of the latest device pack 9.
Request to pull logs from the server (in the UI, Administration > Settings > Logging) shortly after running the configDiff query
From what is seen from the logs is that it confirms what was able to find locally: if the device was added to PI's inventory by hostname instead of by IP, then the hostname needs to be specified as the device request parameter for the configDiff request. The deviceName response parameter of the Devices resource is what you're looking for. (So in your case, /op/configArchiveService/configDiff/cob1-oet...)
The documentation for this resource is incorrect and misleading, so we'll address that. The description for the device request parameter should read: The device name or the management address of the device. The management address is the address used to add the device to the managed inventory, either an IP address or hostname.
Furthermore, the deviceIp response parameter is a bit of a misnomer, and it's description should read: The management address of the device. The management address is the address used to add the device to the managed inventory, either an IP address or hostname.
So in summary, you can specify either the device name or the management address of the device to configDiff. If the device was added by name, device name and management address are often the same (device.example.com) but may be different (device name is self-reported and configurable, but the management address must resolve and be reachable from PI). In the case of discovery, where you don't know what type of management address was used to add the device to inventory, would recommend using device name instead.
Lastly, I just want to make sure that you're aware that the documentation available on developer.cisco.com is also available on your Prime Infrastructure server (visit https://your_server/webacs/api/v1). A couple of the advantages of viewing the docs from your server is that they'll most closely match your server (and include any changes we made in maintenance releases, which we generally don't post to DevNet) and they offer a search bar.
- Thanks for the location information on the API for Prime, it is similar to ISE with the API information located on the server.
- Tried the cURL statement with the device name and then the management IP but with no luck. Trying to delete and add the device to see it is works want to know how it was added via the name or IP address. Here are the results from the cURL commands and a screen shot from our Prime.
- $ curl -k "https://xxxxxx:email@example.com/webacs/api/v1/op/configArchiveService/configDifffirstname.lastname@example.org/webacs/api/v1/op/configArchiveService/configDiff/cob1-oet.r.state.mn.us"
- $ curl -k "https://xxxxxx:email@example.com/webacs/api/v1/op/configArchiveService/configDifffirstname.lastname@example.org/webacs/api/v1/op/configArchiveService/configDiff/172.25.232.1"
- [dsampson@mnet-ws-dave prime]$
You can create a TAC case if you like, we can continue to try to solve the issue here, or both.
If it's an option, yeah, try to delete the device and it back.