Migrating Cisco Meraki switches from CS firmware...

Firmware upgrades are often viewed as routine maintenance, but some introduce architectural changes that require more planning than expected. I recently migrated a Cisco Meraki switching environment from CS firmware to IOS XE. While the migration was ultimately successful, it highlighted several important differences in how management networking and routing are handled. If you are planning a similar migration, understanding these changes ahead of time can save hours of troubleshooting.

Original design

Before the migration, our switches used a dedicated management network that was separate from the Layer 3 Switch Virtual Interfaces (SVIs). Under CS firmware, the management IP address operated independently of the switch's routing configuration. The management interface had its own gateway, while the distribution switch maintained a separate default route for production traffic.

Upgrade to IOS XE

After upgrading to IOS XE, we quickly discovered that one key architectural difference from CS firmware is the removal of the standalone management interface.

Instead of using a dedicated management IP address and gateway, IOS XE integrates management traffic into the Layer 3 routing table. As we worked through the migration, we found that the distribution switch's default route was taking precedence over the expected management path. After reviewing the configuration several times, it became clear that this behavior was tied to the IOS XE management architecture.

Understanding the Preferred Uplink feature

After several conversations with Meraki Support, they pointed us to Cisco's documentation on the Preferred Uplink feature in Cloud Management with IOS XE. The documentation explains that management traffic now follows the switch's routing table instead of using a dedicated management gateway. IOS XE uses Preferred Uplink to maintain connectivity to the Meraki Dashboard by dynamically installing Dashboard-specific routes if the preferred uplink becomes unavailable.

During those discussions, we learned that IOS XE 17.18.3 introduced enhancements that allow management traffic and the default route to remain separate, providing behavior much closer to the legacy CS firmware. After upgrading to the newer release, the routing conflict was resolved, and the migration became much smoother.

Understanding these architectural changes explained why our previous CS design no longer behaved as expected. It also reinforced the importance of reviewing firmware release notes before beginning a migration.

Lessons learned

Looking back, the migration reinforced a few important lessons.

First, migrating from CS firmware to IOS XE is more than a firmware upgrade; it changes the underlying management architecture. Existing management network designs that worked perfectly under CS firmware may require modifications once management traffic becomes part of the Layer 3 routing table.

Second, stay current on firmware releases. The newer IOS XE version we ultimately deployed included enhancements that simplified the migration and restored functionality similar to what we had under CS firmware.

Final thoughts

Our migration required additional firmware upgrades, several discussions with Meraki Support, and a few management network adjustments before everything worked as expected. Although the process took longer than anticipated, it provided a much better understanding of how IOS XE handles management traffic and routing. If you are planning a migration from CS firmware to IOS XE, take the time to review Cisco Meraki's documentation on Layer 3 SVI behavior and Preferred Uplink before your maintenance window. Understanding these architectural differences beforehand can help prevent unexpected routing issues and make your migration significantly smoother.