Eigene Plattform oder Cloud-Dashboard für Switches und WLAN?

Zwei Betriebsmodelle: lokale Appliance gegen Cloud-Dashboard

Catalyst Center ist der neue Name von Cisco DNA Center. Die Release Notes der Versionslinie 2.3.7 erscheinen bei Cisco unter beiden Namen, und neuere Versionen der Linie 3.x laufen nur noch als Catalyst Center. Die Plattform gibt es als DN3-Appliance auf Basis von Cisco-UCS-Servern C220 und C240 und als virtuelle Appliance auf VMware ESXi oder in AWS. Sie gliedert sich in Design, Policy, Provisionierung, Assurance und Plattform.

Das Meraki-Dashboard ist ein Cloud-Dienst. Die Geräte bauen eine Verbindung zur Cloud auf, holen dort ihre Konfiguration und melden ihren Zustand. Der Nutzdatenverkehr läuft nicht über die Cloud, sondern direkt im LAN oder über das WAN. Eine Organisation wird bei der Registrierung einer Region zugeordnet, für Europa der EU-Region.

Der Unterschied im Alltag liegt in der Verantwortung. Bei Catalyst Center gehört die Plattform zum eigenen Betrieb, mit Wartungsfenstern für Updates, Sicherung, Monitoring der Appliance und einem Konzept für ihren Ausfall. Beim Dashboard verantwortet Cisco die Plattform, und dein Team konzentriert sich auf das, was darin konfiguriert ist.

Matrix: Funktionen, Datenhaltung, Lizenz und Personalbedarf

Die Tabelle fasst die Unterschiede zusammen, die in Ausschreibungen und Betriebskonzepten am häufigsten gefragt werden. Sie ersetzt nicht den Blick in die Funktionslisten der jeweiligen Version, denn beide Plattformen entwickeln sich mit jedem Release weiter.

Datenschutz und Datenstandort des Cloud-Dashboards

Meraki beschreibt die EU-Region so: Das Dashboard für Organisationen in der EU-Region wird in Rechenzentren gehalten, die geografisch in der EU liegen. Nutzdaten laufen nicht durch die Cloud, und Endnutzerdaten werden nie an den Primary Controller übertragen. Die Anmeldehistorie der Administratoren wird nur im EU-Rechenzentrum gespeichert.

Der Primary Controller steht laut Meraki in US-Rechenzentren. Er speichert Registrierungsdaten wie die E-Mail-Adresse des ersten Administrators und den Firmennamen, Organisationsdaten wie Lizenzen und Administratoren und Netzdaten wie Namen, Zeitzonen und Tags. Er speichert außerdem die Anmeldedaten der Administratoren und Nutzer des Dashboards.

Für die Datenschutzprüfung heißt das: Die Telemetrie und die Daten der Endgeräte bleiben in der EU, aber personenbezogene Daten der Administratoren und Organisationsdaten liegen in den USA. Das ist eine Übermittlung in ein Drittland, die der Datenschutz bewerten muss. Bei Catalyst Center auf eigener Hardware stellt sich diese Frage nicht, solange keine Cloud-Dienste angebunden werden.

• Setze die Region der Meraki-Organisation bei der Registrierung auf Europa.

• Nimm die Liste der Daten beim Primary Controller in die Datenschutzprüfung auf.

• Sichere die Administratorkonten mit Single Sign-on und eigener Anmeldung ab.

• Halte bei Catalyst Center fest, welche Cloud-Anbindungen aktiv sind und welche Daten sie übertragen.

Mischbetrieb und gemeinsame Übersicht

Viele Unternehmen landen in beiden Welten: Catalyst Center in der Zentrale, Meraki in den Filialen. Für diesen Fall bietet Cisco die Global Overview im Meraki-Dashboard. Sie fasst Zustand und Alarme von Meraki-Organisationen und Catalyst-Center-Instanzen zusammen, zeigt Netze und Standorte nach Zustand und listet Geräte, die offline sind oder Probleme haben.

Die Global Overview dient der Beobachtung, nicht der Konfiguration. Meraki schreibt ausdrücklich, dass an Catalyst-Center-Organisationen dort keine Konfiguration möglich ist. Über die Suche springst du in die Ansichten von Catalyst Center, etwa Device 360 oder Client 360, und mit gleichem Benutzernamen in beiden Systemen ohne erneute Anmeldung.

Die Anbindung hat Voraussetzungen. Jede Catalyst-Center-Instanz muss bei der Cisco Catalyst Cloud registriert sein, und Meraki nennt bestimmte Versionen als Voraussetzung, für die virtuelle Appliance mindestens 3.1.6. Eine Instanz kann entweder mit dem Catalyst Center Global Manager oder mit dem Dashboard verbunden werden, nicht mit beiden.

Hardwarefrage: Catalyst-Geräte in beiden Welten

Früher legte die Hardware die Plattform fest: Meraki-Geräte ins Dashboard, Catalyst-Geräte in DNA Center. Das gilt nicht mehr. Die Wi-Fi-7-Access-Points der Serie CW917x haben eine Unified License mit einer einzigen Produktnummer und lassen sich mit einem Catalyst-9800-Controller oder in der Meraki-Cloud betreiben. Beim Zurücksetzen auf Werkseinstellungen wählst du zwischen Catalyst-Modus und Meraki-Modus.

Catalyst-9000-Switches lassen sich ab bestimmten IOS-XE-Versionen in den Cloud-Betrieb mit Konfiguration über das Dashboard umstellen. Meraki nennt dafür unterstützte Modelle aus den Familien C9200, C9200L, C9200CX, C9300 und C9500H und je Modell eine Mindestversion, bei der C9200L und C9300-M ab 17.15. Die Umstellung löscht die gesamte Konfiguration und alle lokalen Dateien und braucht Images im Installationsmodus.

Daneben gibt es die reine Cloud-Überwachung für Catalyst-Switches. Dabei bleibt die Konfiguration bei der Kommandozeile oder Catalyst Center, und das Dashboard zeigt nur Zustand und Ereignisse. Meraki verlangt dafür eine aktive DNA-Essentials- oder DNA-Advantage-Lizenz und bestimmte IOS-XE-Versionen.

! IOS-XE-Version, Modell und Lizenzstand festhalten
show version
show license summary
! Installationsmodus statt Bundle-Modus?
show install summary
! Konfiguration und Dateien vor dem Zurücksetzen sichern
copy running-config tftp://10.10.5.20/sw-lager-01.cfg
dir flash:

Betrieb, Ausfallsicherheit und Automatisierung

Catalyst Center ist selbst ein kritisches System. Fällt es aus, laufen Switches und Access Points mit ihrer Konfiguration weiter, aber Provisionierung, Assurance und Vorlagen stehen still. Für die virtuelle Appliance verweist Cisco im Datenblatt auf die Hochverfügbarkeit von ESXi, für die Appliances gibt es Cluster- und Disaster-Recovery-Konzepte. Zum Betriebskonzept gehören Sicherungen der Plattform, ein Plan für Upgrades und ein Test, ob eine Wiederherstellung tatsächlich gelingt.

Beim Meraki-Dashboard verlagert sich die Frage auf die Internetverbindung der Standorte. Ohne Verbindung zur Cloud arbeiten die Geräte weiter, aber du siehst sie nicht und kannst nichts ändern. Für Catalyst-Switches im Cloud-Betrieb gibt es eine lokale Statusseite für grundlegende Änderungen, etwa an der Uplink-Adresse, damit ein Gerät nach einer Störung wieder in die Cloud findet.

Beide Plattformen bieten REST-Schnittstellen, über die sich wiederkehrende Aufgaben automatisieren lassen, und für beide gibt es Ansible-Collections. Wer bereits mit Ansible oder Python gegen die Kommandozeile arbeitet, sollte prüfen, wie viel davon über die Plattform-API einfacher wird und was bei cloud-verwalteten Switches ohne schreibenden Konsolenzugriff entfällt.

• Catalyst Center: Sicherung, Wiederherstellungstest, Upgrade-Fenster und Ausfallkonzept der Plattform

• Meraki: redundante Internetanbindung an wichtigen Standorten und Zugang zur lokalen Statusseite

• Beide: Rollen und Rechte der Administratoren, Single Sign-on und Protokollierung der Änderungen

• Beide: vorhandene Skripte und Playbooks auf die Plattform-API umstellen oder bewusst behalten

Entscheidungshilfe nach Betriebsgröße

Ein kleines Unternehmen mit einem Standort und einer IT-Abteilung von wenigen Personen hat selten Zeit, eine eigene Management-Plattform zu pflegen. Hier spricht viel für das Dashboard, sofern der Datenschutz die Verarbeitung beim Primary Controller in den USA akzeptiert.

Ein Mittelständler mit Zentrale und vielen Filialen profitiert oft von einer Aufteilung: Das Dashboard für Filialen ohne eigene IT und, wenn die Zentrale es braucht, Catalyst Center für den Campus. Die Global Overview verbindet beide Sichten, und mit der Networking Subscription müssen die Lizenzen nicht doppelt gekauft werden.

Ein großer Campus mit Anforderungen an Segmentierung, mit Fabric-Betrieb und mit strengen Vorgaben zur Datenhaltung führt fast zwangsläufig zu Catalyst Center. Hier ist die Voraussetzung ein Team, das IOS XE, die Plattform und SD-Access beherrscht oder aufbaut.

• Ein Standort, kleines IT-Team, Cloud-Freigabe vorhanden: Meraki-Dashboard

• Viele Filialen ohne eigene IT: Meraki-Dashboard, in der Zentrale je nach Bedarf Catalyst Center

• Großer Campus mit Fabric, SD-Access und tiefer Analyse: Catalyst Center

• Strenge Vorgaben zur Datenhaltung im eigenen Haus: Catalyst Center auf eigener Hardware oder ESXi

• Beide Plattformen bereits im Einsatz: Global Overview für die gemeinsame Sicht