Running Meraki MR APs and Catalyst 9xxx APs together

[gcarmich]

Can Catalyst 9xxx APs be opersted in an Meraki AP environment?

Can Catalysr 9xxx APs be integrated into an existing Meraki AP environment?

[Purroy]

Yes, the CW916x family can run in Meraki Dashboard the same way MRs do. 

Upon ordering make sure you get the right SKU so they come from factory ready to be used in Meraki Dashboard:

CW916Xi-MR comes ready for Meraki Dashboard. Aka Meraki Persona

CW916Xi-E/A/B or other terminations come ready for Cisco WLC/Catalyst center. Aka Catalyst persona 

Any SKU can be changed from one persona to the other. 

[KarstenI]

There is an important implication is Purroy’s answer: The Wi-Fi 6 APs (non 916x) don’t support the Meraki Persona. But if you have a 9800-L/40/80 with these APs, this can be added into the dashboard for monitoring.

[Purroy]

Correct, I guess a better way to put it is that all WiFi6E AP, except the C9136i (only WLC) and MR57 (only Meraki), are dual personas APs and can be fully managed by Meraki Dashboard or Cisco WLC/Catalyst Center. Those are the ones with the CW916X nomenclature.  See above to choose the right SKU for your desired persona. 

For the c9136i, most of the Cisco WiFi6 and WiFi5 APs controlled by physical Catalyst WLCs will be able to be monitored (not fully managed) by Meraki Dashboard in the near future. This exciting capability is now in Beta and was announced in Cisco Live Amsterdam 2024. 

[gcarmich]

Thank you.

I think I already know the answer to this question but would like to confirm:  Could a Catalyst AP network be deployed effectively in a pre-existing Meraki AP environment without integrating the network controllers of the two networks (--networks operating independently)?  Would this situation create competition in the RF environment and impact SNR?  Would client devices be able to roam between the two networks?

[KarstenI]

So much makes this a terrible idea as a permanent solution, but it could be acceptable as a temporary solution while the migration is ongoing.

Clients will be able to roam. But roaming is always affected. For .1X, there will always be a slow roam between the two worlds, and the clients must go through the entire EAP exchange with the radius server. This is fine for PSK, as the handoff from one AP to the other is always relatively fast.

Regardless of .1X or PSK, the client has less power to choose the next roam candidate as the neighbor reports will not include the APs of the other technology. And you need to ensure that the other world is not classified as rogue APs.

[alemabrahao]

Just a correction, actually no roaming because RF information will not be exchanged if they are on different controllers or even if they are autonomous.

[gcarmich]

Thank you.

And would the Wi-Fi RF environment be degraded since both networks would be competing for spectrum?

[KarstenI]

If you leave the systems alone to decide about channels and power, they don't really consider the other world. It is more or less interference and both systems will try to avoid it. But they try it independently. In general, it will work much better when you can restrict the channel width (no 80s, only 40s, or even 20s, depending on the amount of APs you have). It will be more challenging than a WLAN based on one vendor. I would get a consultant to evaluate the best way to implement it.

[KarstenI]

It is still considered a roam as the client moves from one BSSID to another BSSID of the same SSID. Only if both systems use different SSIDs, it would be debatable if we still can name it roaming. In that case, I normally would not name it roaming. But roaming itself doesn't need any exchange of RF or neighbor information. It just makes the roaming experience much better.

[alemabrahao · Accepted solution]

It may be, but it is less efficient and makes it slower.

My advice is not to have two wifi ecosystems.

Centralizing everything will enable a more efficient network and a "cleaner" WiFi spectrum.

[KarstenI]

Well, I was hoping that it was more than clear that I never said anything else.