In today’s article, we will focus on Meraki management for Cisco Catalyst 9300 switches in Cloud Management model migration. Let’s see if the process itself goes as smoothly as it did with the Catalyst 9200 switch. I have a model with software upgraded to version 17.12.01, the latest as of the date of this article.
The dust hasn’t yet settled in our lab after the migration of the Cisco Catalyst 9200 switch in Cloud Monitoring mode and the CW916X series access point to the Meraki dashboard, and I’m taking on another representative of the Catalyst family switches, the 9300 model, more specifically: C9300-48UN. Let’s recall what was mentioned in the article on Catalyst 9200 switch migration, this switch series can be migrated to Meraki management in two modes:
At the very beginning, you need to remember one very important point: during the switch migration process, the switch’s configuration, internal memory (flash:), connected external memory (e.g. usb-flash) and other media will be formatted and adapted to work with Meraki software. Why so? Well, because, again recalling the previously cited article on Catalyst 9200 migration to Cloud Monitoring mode:
A Catalyst 9300 switch managed by the Meraki dashboard in Cloud Management mode will no longer be an IOS-XE-based device! It will run Meraki software on it and this change is fully reversible. Stacks are also supported. For monitored-only switches, the software remains unchanged and you can still log into its CLI and manage it in the traditional way.
Therefore it is advisable to unplug the external media and back up those files we don’t want to lose. When we’re sure we have it, we can start the migration.
We start by checking hardware and software compatibility with the show meraki compatibility command:
As you can see above, my appliance was fully compatible, so theoretically Cloud Management migration should succeed. However, if I tried to migrate the switch with partial compatibility, the process would fail, as we would be informed by a creator error.
We check the switch’s connection to the Meraki management
At that point, we need to ensure that the switch has a DNS configuration capable of resolving this name, to indicate a default gateway that is capable of connecting to the Internet, and of course that it has the L3 interface configured.
That’s basically it. If the above test is successful, we can proceed to register the switch in the Meraki management.
For a single switch, we type the service meraki register command, while for a stack of switches service meraki register {the number of the switch in the stack}. The result is the successful registration of our copy (copies). It’s a good idea to copy the following values to yourself for later use in the Meraki management dashboard.
“If I make another move, there’ll be no more turning back
Because everything would change and it all would fade to black” ~ Bad Apple, RichaadEB & Christina Vee
We have come to the point where executing the next command will change everything (although mostly reversibly, as discussed further in the article). Read the following warnings and make sure that executing the last command will not cause any inconvenience:
If everything is clear and there are no objections, we initiate the switch changes with the service meraki start command.
As mentioned above, previewing the migration is possible using a console wire connection, so I switched to this interface.
After issuing the service meraki start command, the switch once again makes sure we are aware of what we are doing:
We confirm and get the last information about the migration to cloud management in Meraki dashboard. Especially important is the information that the whole process can take up to two hours, so you will have to be patient.
After another confirmation, after a few minutes, you will see that the switch has started in Meraki management mode and that the device’s console interface is in read-only mode:
Now you can take care of adding the switch to your existing Meraki dashboard. As a reminder, if you don’t have one, you can register for free, instructions here.
In the switches view, press the “Add a switch” button:
Then click on the “Claim” button and enter the Meraki ID of the switch(es) acquired in the device registration process:
Then select the switch(es) from the list and click on “Add devices.”
That way, the switch(es) will be visible in the dashboard. Then I configured the uplink on the switch to allow it to communicate with both the local network and the Internet (specifically with dashboard.meraki.com). Basically, we use here (as mentioned above) the configuration for the MS390 switch. Theoretically, it is enough to connect the switch to a subnet with a DHCP server for everything to work automatically. I, however, did not have such a subnet, so I had to configure a static IP address. I used a computer, connected with a network cable to the management port on the back of the device. My computer received an IP address from DHCP, specifically: 192.18.0.2, and the default gateway was 192.18.0.1. The management interface was available in the browser at this address.
To change the switch’s settings, you had to log in with your Meraki ID, according to the message.
I was able to assign a static IP address to the switch on the port of my choice in the “Uplink configuration” tab.
Not a quarter-hour had passed when the switch appeared in Meraki management dashboard fully ready for configuration.
The configuration capabilities cover all aspects of the switch, such as the ability to configure ports or global settings. You can view the current status of the device, read logs and much more – all using Meraki’s convenient cloud-based dashboard.
The process of reverting to IOS-XE involves, as with the CW916X series access points, setting up a ticket in Meraki’s dashboard requesting that the switch be restored to its original form (removing the switch from the Dashboard and restarting the switch with IOS-XE software). Support should grant our request within a day. I, on the other hand, am still waiting for the possibility of doing the “return” conversion myself – shouldn’t it be done by any chance with one “button” directly from the Meraki management console? What is it that stands in the way? Hopefully, time will bring such a possibility as well.
In a few words: I am amazed by the ease and transparency of the whole process and the maturity of its implementation. To make the revolution that turns the Cisco Catalyst 9300 into a Meraki device, all you need to do is meet a few simple conditions, back up your files and settings (if you feel the need) and use a few simple commands in the switch interface. And that’s it!
Everything worked without any surprises. It’s safe to say that just now I got rid of my distaste after the bumpy road of converting the CW916X series access point to the Meraki management dashboard, which I described here.
Cisco has had stumbles, however, in the end, it is able to prove that in the market of network devices, it was and is the leader. The freedom to choose between on-premise and cloud management is no longer a curiosity, but a fact – even in such a conservative device segment as enterprise networking.
If you’re wondering how else you can improve the management of your switches or other network infrastructure components, schedule a service consultation. We will help you optimize the configuration of your devices.