cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4065
Views
2
Helpful
10
Replies

Get Configuration Diff api

dasampson
Level 1
Level 1

Might be the wrong place to post, but I thought I would ask.

I am 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.  Is there another place that I can find the documentation on how to use this?

Here is the link to the API guide, Cisco DevNet: prime-infrastructure - REST API - v3.1 API Reference

Thanks

Dave

1 Accepted Solution

Accepted Solutions

Spencer Zier
Cisco Employee
Cisco Employee

Ooh, looks like there's a problem with this and some of the other pages in our scrape of the API docs.  Thanks for raising this issue.  I'll have to look into this.

In the meanwhile, to address your immediate need, you can download this PDF of the doc page: config_diff.pdf - Box

View solution in original post

10 Replies 10

Spencer Zier
Cisco Employee
Cisco Employee

Ooh, looks like there's a problem with this and some of the other pages in our scrape of the API docs.  Thanks for raising this issue.  I'll have to look into this.

In the meanwhile, to address your immediate need, you can download this PDF of the doc page: config_diff.pdf - Box

So am I using this correct?  (I assume not because I am getting an error ) Because I get:

[dsampson@mnet-ws-dave ~]$ curl -k "https://user:pass@cpi/webacs/api/v1/op/configArchiveService/configDiff/172.25.232.1"

<?xml version="1.0" ?>

<errorDocument>

  <httpResponseCode>500</httpResponseCode>

  <httpMethod>GET</httpMethod>

  <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>

  <uriPath>op/configArchiveService/configDiff/172.25.232.1</uriPath>

  <queryParams>{}</queryParams>

</errorDocument>[dsampson@mnet-ws-dave ~]$

[dsampson@mnet-ws-dave ~]$

Hmm, 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")';

Odd, what version of PI are you using?  Have you installed any patches/updates?

CPI version 3.1 will all the updates with the exception of the latest device pack 9.

Dave, could please you pull logs from the server (in the UI, Administration > Settings > Logging) shortly after running the configDiff query?  Please reach out to me via email (my address is on my communities.cisco.com profile for logged in users).

Thank you for sending the logs.

From what I can see in them, it confirms what I 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 sum, 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, I'd 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.

I hope this resolves your issue!  If not, please do reach out to me, and please do reach out with any other issues you come across.

Thanks for the location information on the API for Prime, it is similar to ISE with the API information located on the server.  I wasn’t aware of that.

I did try the cURL statement with the device name and then the management IP but with no luck.  Should I delete and add the device to see it is works once I know how it was added via the name or IP address?  Also, if I need to submit a TAC case on this, just let me know.  I don’t want to waste your time.

Here are the results from the cURL commands and a screen shot from our Prime.

$ curl -k "https://xxxxxx:xxxxxxx@somcpi.mnet.state.mn.us/webacs/api/v1/op/configArchiveService/configDiff/cob1-oet.r.state.mn.usxxxxxxx@somcpi.mnet.state.mn.us/webacs/api/v1/op/configArchiveService/configDiff/cob1-oet.r.state.mn.us"

$ curl -k "https://xxxxxx:xxxxxxx@somcpi.mnet.state.mn.us/webacs/api/v1/op/configArchiveService/configDiff/172.25.232.1xxxxxxx@somcpi.mnet.state.mn.us/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.