Manage Cisco APs from the Meraki cloud

Migration from on-premise environment to Meraki dashboard

The new Cisco CW916X series of access points currently includes the CW9162, CW9164 and CW9166 models. It is revolutionary not only because it introduces Wi-Fi 6E technology in the segment of devices for business of various scales, but because CW9166 are equivalent to 9130AXI. It turns out that this series of access points is the first that can be managed in two ways, both using the local wireless controller and using the Meraki dashboard. This is possible due to the fact that these devices come with two pre-installed systems: Catalyst and Meraki.

NOTE! Already at the ordering stage, you can choose which one should run by default – more information on this subject in the Meraki documentation.

This is great news for everyone who plans to purchase and implement a wireless infrastructure and think about resigning from managing these devices using the local environment in the future (or vice versa), or simply being able to plan network infrastructure without unnecessary restrictions. Just knowing that it is possible gives you a lot of peace and confidence. The investment will be right, no matter what the future holds. More details about this series of access points and their technical parameters are available on the manufacturer’s website.

Quite recently, I showed the process of migrating a Cisco Catalyst 9200 switch to the Meraki cloud, whose monitoring I transferred to the Meraki dashboard.

What problems did I encounter during the migration?

At Grandmetric, we also say “I check” this time. We acquired a still warm copy of the Cisco CW9162I-E access point to see how effective the AP migration process is with a local, virtual Catalyst 9800-CL wireless controller. For this purpose, I decided to configure the system from scratch.

Problem 1 – controller version

I downloaded a limited-time trial version of the 9800-CL controller from the Cisco website and embedded it in a virtual environment. According to the manufacturer, the CW916X series access points are supported by the Catalyst 9800-CL controller from IOS XE 17.9.1 and above. The wireless controller I downloaded was originally version 17.06.04, so the next step was to update it to the newer version mentioned above. Unfortunately, problems arose at this stage.

• The controller was not stable after the update.
• WebUI functioned unstable and it was not the fault of the browsers used (I used all three in the latest versions: Google Chrome, Mozilla Firefox, Edge).
• The interface was stuck and stopped responding in places, sometimes the so-called glitches were visible: errors in the operation and appearance of the interface, manifested by problems with encoding subtitles or the inability to use e.g. drop-down lists. The situation was greatly improved by updating to the latest version available at the time, 17.10.1. The interface stabilized, and I was able to easily perform the basic configuration of all required profiles to prepare the wireless controller for access point adaptation.

Problem 2 – power source

So it’s time to connect it to the network. In parallel, to watch the adaptation process in real-time, I connected the device with a console cable. Imagine my surprise when the first error visible in the console was the mysterious condition critical state 4, without more extensive explanations.

Fortunately, the device LED told me that the power was not enough, changing colours alternately. I was a bit surprised by this fact because the specification clearly says that the power supply that meets the PoE (802.3at) standard should be sufficient to start and operate the access point but with some limitations (the LAN interface can then work with a maximum bandwidth of 1 Gbps, not all radio frequencies are available though). So I replaced the power source supporting PoE+ and the problem disappeared – the device received an IP address from the DHCP server and the controller started to adapt it.

Initially, I thought that the situation was normal – the device appeared in the controller’s inventory, and its status did not raise any objections, but after a few minutes strange things began to happen: in the dashboard, in the Radios tab, all frequencies (6 GHz, 5 GHz, 2.4 GHz) changed their status from up to down, while the access point changed from operational to connected but not operational. Then, after a while, the situation was reversed again – everything was fine, only to repeat the process a few minutes later – and so on, endlessly.

The wireless controller and device restart spells didn’t help here. I decided to remove the controller and reinstall and configure it. I did the same with the access point. Unfortunately, it didn’t change anything.

Newest version to the rescue! 

I had to start troubleshooting, but due to the limited time, I was forced to postpone the topic for about a month to return to it in the second half of April. Also, this time I decided to perform troubleshooting in the tabula rasa model – reinstalling the wireless controller, and resetting the access point.

This time, however, I noticed that Cisco offered to download the controller software one step higher – 17.11.1. I decided to install this version and it looks like it was worth the wait. The controller in this version works very stably, the configuration runs without any problems, and the access point itself has been adapted quickly and flawlessly. In addition, the controller has updated its software.

At this stage, the question arises: was it the fault of previous versions of the controller, or maybe the device software? It’s hard to say, but I have to admit that in the face of previous experience, it’s worth keeping both elements in the latest version.

We migrate to the Meraki dashboard

I have to admit that my experience so far with the latest versions of both the Catalyst 9800-CL wireless controller and the CW916X series AP is very disappointing. Fortunately, it seems that Cisco managed to tame these products and we can proceed to the clue of this article, i.e. the migration of the access point to the Meraki dashboard.

The process itself looks uncomplicated and I carried it out based on the official Cisco documentation. We need to be sure of two things before we start:

1. Access points should have a DNA license,
2. Devices must be able to connect to the Meraki dashboard. Details in the documentation.

The entire migration is completed in a few quick steps

And about the success of the process:

Cisco recommends waiting a few minutes before disconnecting the access point from power after this process. From now on, the device in the controller dashboard is visible only in the following way:

It is worth doing this because the information in this section will only be visible until the controller is restarted. When exporting, select Export to Meraki Dashboard.

And then

In my case, the process took about 5 seconds. I received this message:

Cisco DNA Licensing on the Meraki Cloud

Device adaptation will take a while (for me it was about 15 minutes, but it can be even more, you have to be patient), in the meantime we can solve the license problem. The License issue button in the upper part of the window, visible in the screenshot above, informs us about its existence.

Interestingly, the length of the contract will remain the same or will be extended to the full billing period, i.e. if you have 22 months of Cisco DNA support and license left, you will receive a 24-month Meraki license.

To do this, you must complete the form available on the Cisco Meraki website.

You will need your Meraki instance and migrated device details. After verifying these data, the system should qualify the DNA licenses used so far for use in Meraki. You will receive them by e-mail and you will have to paste them in your dashboard.

NOTE: the previous licensing is still valid, so you can return the AP to the current management model (with the Catalyst on-prem wireless controller) because the DNA licenses remain unchanged for further use.

And that’s it, now you can enjoy access points managed from the Meraki dashboard with all its benefits. However, you must remember a major limitation, which is the lack of access to the CLI of the device.

Are these changes reversible?

The answer is yes. After converting the AP into a model managed by the Meraki dashboard, the access point’s bootloader informs us when the power is connected that the Meraki mode is selected, i.e. the Meraki image is simply loaded.

However, if you want to convert the device back to local controller management mode, you will need to contact Meraki support where you express the need. This is a rather strange approach, and I believe that it is rather a matter of time until Cisco engineers automate this process and it can be done with one click directly from the Meraki dashboard. More in the Catalyst 9166 and 9164 deployment manual.

Bitter taste of migration

As you can see, the whole process was not as seamless and simple as in the official Cisco documents. It is difficult to say at the moment what could have caused this, but most likely the errors are caused by underdeveloped wireless controllers and/or access point software. After updating both to the latest version on the date of publication of the article, everything went smoothly. It should be remembered that despite the passage of several months, these devices are still new to the market and it will probably take some time before all the “infancy” problems of these access points and their management methodology will be detected and removed. Half-measure in the form of forced contact with Meraki support in order to change the management mode to local seems to be the best confirmation of my thesis here.

Is it worth getting interested in this series of products? Definitely yes. Finally, you don’t have to think, anticipate the unpredictable and try to fit in with the development of your business. Access points of the CW916X series will allow you to manage freely regardless of your plans, situation and infrastructure.