Catalyst Center ist eine API mit Oberfläche — nicht umgekehrt

Es gibt einen Zustand, den man in vielen Häusern nach einer Catalyst-Center-Einführung findet: Die Appliance läuft, die Geräte sind entdeckt, die Health-Scores sind grün — und jemand klickt. Rollouts laufen über die Oberfläche, Software-Stände über die Oberfläche, Reports über die Oberfläche. Die Plattform funktioniert, aber sie arbeitet nicht mit.

Das ist kein Bedienfehler, sondern eine Folge der Reihenfolge: Wer eine Plattform über ihre Oberfläche kennenlernt, denkt sie als Oberfläche. Cisco dokumentiert sie anders — als Programmierschnittstelle mit drei Richtungen, zu der eine Oberfläche gehört.

Drei Richtungen, nicht eine Schnittstelle

Die Unterscheidung ist mehr als Nomenklatur. Northbound ist der Weg, auf dem Ihre Automatisierung der Plattform etwas aufträgt. Eastbound ist der Weg, auf dem die Plattform Ihnen etwas meldet, ohne dass jemand nachsieht. Westbound ist der Weg zu den Systemen, in denen die Organisation ohnehin arbeitet — Ticket, Bericht, Auswertung. Wer nur northbound denkt, baut Automatisierung, die niemand mitbekommt.

Was sich damit tatsächlich automatisieren lässt

Die Dokumentation nennt als Funktionsbereiche Geräte-Lebenszyklus, Provisionierung, Software-Verwaltung, Compliance, Inventar, Policy-Verwaltung und erweiterte Analytik. Praktisch heißt das:

• Onboarding ohne Labortisch. Neue Geräte kommen über Plug and Play in die richtige Site, mit dem richtigen Software-Stand und der richtigen Vorlage — ausgelöst aus dem Inventar, nicht aus dem Kopf.
• Software-Wellen als Vorgang. Ein Zug, eine Gruppe, ein Zeitfenster, ein Nachweis. Was heute eine Terminserie im Kalender ist, wird ein Lauf mit Ergebnis.
• Compliance als Abfrage. Die Abweichung vom Soll-Zustand lässt sich abfragen, statt sie zu bemerken. Das ist der Unterschied zwischen einem Audit und einer Überraschung.
• Reports ohne Handarbeit. Inventar, Software-Stände und Health-Verläufe wandern über die Integration API dorthin, wo sie gelesen werden — nicht dorthin, wo sie erzeugt wurden.

Für den Weg dorthin stellt Cisco mehrere Werkzeuge bereit: Python, Ansible und Terraform. Rechte laufen über rollenbasierte Zugriffskontrolle — was für automatisierte Zugriffe wichtiger ist als für menschliche, weil ein Dienstkonto mit Vollrechten der bequemste Weg und der schlechteste ist.

Neben NetBox und Ansible — nicht statt

Die häufigste Fehlannahme bei der Einführung: Catalyst Center ersetze die vorhandene Automatisierung. Tut es nicht, und sollte es nicht. Die Plattform ist stark für Catalyst-Infrastruktur; sie ist keine Source of Truth für alles, was im Haus am Netz hängt.

Diese Grenze gehört vor der Einführung gezogen, nicht danach. Zwei Automatisierungen, die dieselbe Konfiguration für sich beanspruchen, erzeugen keinen doppelten Nutzen, sondern einen Konflikt mit Zeitstempel.

Der Name in Ihren Unterlagen

Was das für die Einführung heißt

1. 01

   Die Grenze zuerst ziehen

   Was gehört in die Source of Truth, was übernimmt die Plattform? Diese Antwort entscheidet über die gesamte Automatisierungsarchitektur und lässt sich später nur teuer korrigieren.

2. 02

   Zugriffe als Rollen bauen

   Ein Dienstkonto je Zweck mit den Rechten, die dieser Zweck braucht. Rollenbasierte Zugriffskontrolle ist dafür vorgesehen — sie wird nur selten genutzt, bevor der erste Vorfall sie erzwingt.

3. 03

   Mit einem Ereignisstrom anfangen

   Ein abonniertes Ereignis, das in einem Ticket endet, beweist die Kette schneller als jedes Provisionierungs-Projekt — und verändert den Betriebsalltag sofort spürbar.

4. 04

   Erst danach provisionieren

   Wenn Inventar, Rechte und Rückmeldeweg stehen, ist automatisiertes Onboarding ein kleiner Schritt. Vorher ist es ein Risiko mit Oberfläche.

Wie wir Catalyst Center einführen und übergeben, steht unter Cisco Catalyst Center; die Automatisierungskette daneben unter Network Automation. Welche IOS-XE-Version dabei auf die Geräte gehört, behandelt der Beitrag zur IOS-XE-Versionsstrategie.