Showing results for 
Search instead for 
Did you mean: 

Prime Infrastructure 3.5 API Preview: A Brief Overview of Changes

Cisco Employee

Hey folks!  While we're wrapping up the development of Prime Infrastructure 3.5 and preparing it for release, I thought I'd update you with some of the changes that we're bringing to the Prime Infrastructure API in 3.5.


Removal of DevNet Integration

Previously, in the 3.2 release of Prime Infrastructure, we added a feature that integrated the discussions on our DevNet community forum into the documentation.  See our blog post about it for more details.  When the merger of the old communities platform and the Cisco support forums was announced, we knew that we would need to revisit this feature.  Unfortunately, as we looked into it, we discovered that the approach that we used on the old platform would not work on our new, merged, platform.  After discussing with folks that manage this in Cisco, and a brief conversation with the vendor, we decided that the best course of action would be to remove this feature from the documentation.  With that one bit of bad news out of the way, let's turn our attention to the good news.


Access Point Rx Neighbors

We've heard from a lot of you that one of the API features that you've been looking for is the ability to fetch Rx neighbors via the API.  I'm pleased to let you know that we've implemented such an API resource in Prime Infrastructure 3.5.  The new API resource, GET op/apService/rxNeighbors, takes in one access point ID (the ID Prime assigns, which you can get from GET data/AccessPoints) and returns a list of neighbors.  Included in that response list is the slot ID and MAC address of the interface that discovered the neighbor; the MAC address of the neighbor; the ID, slot ID, name, service domain, and IP address of the neighbor if known; the neighbor's channel and channel bandwidth, radio band, and RSSI.  While Prime Infrastructure has supported fetching this information via the UI for quite some time, it does not persist this information in it's internal database.  For this reason, please be aware that querying this resource will result in Prime Infrastructure reaching out to your network to fetch live data.


Event Streams via W3C Server-Sent Events

Another big ask from many of our API users has been the ability to get events and updates as soon as they happen, without having to regularly poll API resources over and over again.  So, in essence, as soon as something happens, you've wanted Prime Infrastructure to notify you.  We've been working on this for quite some time.  We wanted to ensure that we picked the right approach that would integrate well into our existing API framework and Prime Infrastructure as a whole.


The technology that we've settled on is W3C server-sent events (SSE).  SSE allows us to send you events, as soon as Prime Infrastructure is aware of them.  SSE works by having your client initiate a long running HTTPS connection to Prime Infrastructure.  This connection allows for asynchronous, one-way communication from Prime Infrastructure to you.  Over SSE, we can push out events as they happen.


There are multiple open-source SSE libraries and clients out there to help accelerate your adoption of this new feature, so you can focus on your specific use cases and business needs.


We will be releasing SSE resources for generic alarms, rogue AP alarms, and CLI templates in Prime Infrastructure 3.5.  We're also planning on broadly expanding this new feature with plenty more SSE resources in the next major release of Prime Infrastructure, but I can't share any details on that just yet.  However, please let us know in the comments which SSE resources you'd like to see.


Stay Tuned for More!

I know some of you interested in our new SSE feature would probably like more details.  I'll be putting up another post next week that walks through some of the specifics of our SSE implementation.  I'll demonstrate how you can use one of the open-source libraries to quickly write up a Prime Infrastructure SSE client, and show how it works in detail.


If you have any questions regarding this please leave a comment, and I'll either get back to you as a reply or give you an answer in my upcoming blog post!


Thanks for pointing me to this page Spencer. 


A concern with the GET op/apService/rxNeighbors API is I will need to send a GET request for each of my APs.  If I had 20,000 APs in the company, I would need to send 20,000 requests to the server.

Is there a summary request for this information? 


Thanks again!



Cisco Employee

Jesse, unfortunately, yes, you'll have to send a request for each relevant AP.  This API limitation is due to a limitation in Prime Infrastructure itself: Rx neighbors are not persisted (primarily because that data grows stale quickly).  Each API request results in traffic out to the device.  In Prime Infrastructure, we have a mediation layer that restricts concurrent traffic to devices by the various Prime Infrastructure components to avoid consistency issues.  These two things (no persistence and mediation) coupled together means that, in the lab when we tried bulk fetches, we saw noticeable slowdowns in Prime Infrastructure's background jobs that fetch information about the wireless network.  Lastly, while fetching neighbors for one AP is fast enough that we can handle it within the timeout of a regular API call (<30 seconds), fetching neighbor info for thousands of APs won't complete in that window, so we have to handle it asynchronously, spin it off as a background job, and give you an ID to monitor the job and fetch the results when ready.  So, for all those reasons, we went with the implementation that we did.


For summary or aggregate information, while we don't have anything for Rx neighbors per se, there are reports and features in Prime Infrastructure can help you solve problems that you might be turning to Rx neighbor information to solve.  For example, we have a coverage hole report to help you identify areas where you might not have enough overlap, RF quality reports to help identify where you might have too much overlap or a need to switch channels, as well as reports for mesh networks to help you ensure they are performing reliably.


I hope that helps!


Thanks Spencer!


Your response is helpful in planning where to go from here.





How do we access the AP Rx Neighbor?


Pass the ID as a Param vlaue?  If so, what is the key?


I am receiving this message and tried a few different key names:

 Access Point Id must be not null op/apService/rxNeighbors {id=[#####]}






Cisco Employee

Jesse, yes, the access point ID is a query parameter.  It's name is "apId", so for an access point with an ID of 12345, the URL would be /webacs/api/v4/op/apService/rxNeighbors?apId=12345


The ID number itself can be retrieved from the GET data/AccessPoints or GET data/AccessPointDetails resources.


For your reference, here's a copy of the documentation page for GET op/apService/rxNeighbors.


Perfect that worked, thanks!

Content for Community-Ad
August's Community Spotlight Awards
This widget could not be displayed.