Over the last two years, I’ve blogged regularly about Wi-Fi 6/6E, what it means, and considerations on how to best adopt these new Wi-Fi specifications. As we continue to help customers move to these newer Wi-Fi specifications, it’s increasingly more apparent that by leveraging APIs, the migration from old to new can be faster, more consistent and generally more positive. This is a quick look at how we’ve seen this unfold for some customers.  

A common term in the world of programming is DRY or “Don’t Repeat Yourself,” which aims to reduce repetition in software patterns. I’m a fan of that concept and try to think about opportunities in all my work that can stand on the shoulders of something I’ve already done or don’t wish to do again. 

In the case of a network upgrade there are usually lots of items that have been configured already, which are tied directly to the device being replaced. For example, in a Meraki network, the admin will hopefully have given the AP a name, an address where the device resides, placed it on a floorplan, set up tags for specific SSID broadcast, and so on. While none of these things take an extraordinary amount of time individually, they do all stack up when put together per device. Beyond that, an admin might be dealing with dozens, hundreds or even thousands of devices in their organization. Once totaled up, the amount of workhours put into management tasks for devices can really be a significant amount of work.

In a Meraki wireless network upgrade where the only change is swapping out an AP model, all of this data will likely remain the same, but the effort would need to be redone because all these elements are distinctly tied to the old APs being pulled from the network. If you could avoid doing all this rework, why wouldn’t you?

In our Meraki example, this is a trivial exercise to be able to take all the desired configuration items for a device and then apply them to the new device. Looking at the Meraki Dashboard API documentation, we can see that a very basic way to accomplish our task would be using the get device and update device endpoints. All the attributes I previously mentioned are available for those endpoints, including a map location in the form of the “floorPlanId” element. Additionally, there are other items that the admin may want to re-use or even modify, such as the IP address or network id, which represents the Meraki network in which the device resides.

From there, it’s just a matter of picking your preferred method to interact with the API. My preference is to write things in Python, so I would typically leverage Meraki’s Dashboard API library that the company maintains so that I don’t have to do all the heavy lifting myself. That isn’t the only answer though, any other language that could interact with a REST API in the cloud would work just fine, and the dashboard API documentation will show examples for curl and Nodejs right on the page. The curl examples are particularly useful as they can be run on any system with the curl application installed and really don’t require any programming knowledge. One last resource worth mentioning is the postman collection that Meraki maintains. Postman even has tools like its runner, which allows running sets of requests in a specified sequence again without needing to write any code.

It would be remiss of me not to briefly talk about the importance of network design while considering an upgrade. An upgrade of networking infrastructure is also an opportunity to look for improvements that can be made in design, process and more. Seemingly, an upgrade to a new model of access point (AP) to adopt a new standard requires little more than purchasing the new model and having it installed. In reality, the existing design may not actually meet the current business needs or expectations for the new technology going in to place. At these critical junctures, we recommend doing some analysis (usually in the form of some sort of wireless survey) to determine if the network might need adjustments. New goals such as a “Wi-Fi first” approach to connectivity or redesigning a building to be a “capacity design” rather than an old “coverage design” model would each require more efforts than just a direct AP replacement to be successful.

That said, there are also perfectly valid reasons where a simple AP placement without a redesign is the right move for the organization. Perhaps the design is already very high density and the newer Wi-Fi standard the replacement AP supports isn’t being leveraged for a feature that requires a design change.

No matter what the driving factors and business decisions are behind a network upgrade, APIs can help recapture efforts and intent that can be reused going forward. CDW can help modernize your organization’s API approach, and to find out how reach out to your account manager and solution architect.

Colin Vallance is a technical architect for CDW with a focus on wireless technologies and automation/programmability. In his role, Colin is responsible for the development of Wi-Fi solutions and services to meet the ever-changing needs of customers. Colin has been at CDW for more than a decade, first as a delivery engineer and then as a technical lead, before becoming a technical architect. During his time in delivery, Colin surveyed millions of square feet, implemented dozens of networks and had the pleasure of working on several CDW stadium projects. He holds a CCIE Wireless, various certifications from Cisco, Aruba and Meraki as well as U.S. patent 10,789,846.