Network Automation · Plan / Build / Operate
Wir bauen die Automatisierungskette für Ihr Netz: Source of Truth, Configuration as Code, Validierung und kontrollierte Ausführung — als Werkzeug für verlässliche Changes, nicht als Selbstzweck.
Automation besprechen4 Leistungen · Network Automation
Gute Automation beginnt bei belastbaren Daten und einem überschaubaren Anwendungsfall. Wir verbinden Source of Truth, Code, Tests und Freigaben zu einem Prozess, den Ihr Team übernehmen kann.
Vorhaben besprechenInventar, IP-Adressen und Sollzustand ordnen — als verlässliche Datenbasis für Ihren Netzbetrieb.
Wiederkehrende Konfigurationen versionieren, prüfen und mit begrenztem Wirkungsbereich ausrollen.
Von der Änderung zum Nachweis: Reviews, Vorher-Nachher-Tests und klare Freigaben in einer Pipeline.
Controller, Inventar und Tickets verbinden — mit nachvollziehbaren Aufträgen und sauberer Fehlerbehandlung.
Der genaue Umfang folgt Ihrer Umgebung und den Abhängigkeiten. Preise, Servicezeiten und Reaktionsziele vereinbaren wir im Angebot.
Leistungsumfang
Die Bausteine einer Automationskette, die Änderungen rendert, prüft und ausrollt — und den Ist-Zustand nie aus den Augen verliert.
NetBox als führendes Datenmodell: Standorte, Geräte, VLANs und Präfixe — abgeglichen gegen die Realität.
Zielkonfiguration aus Jinja2-Templates und strukturierten Daten, versioniert in Git statt in Einzeldateien.
Render, Diff, Dry Run, Freigabe, Deploy: jeder Standard-Change fährt dieselbe geprüfte Strecke.
Pre- und Post-Checks für Routing, Nachbarschaften, Redundanz und Erreichbarkeit — vor und nach jedem Change.
Soll-Ist-Vergleich im Betrieb: Abweichungen werden sichtbar, bevor sie zum Vorfall werden.
Runbooks, Rollen und Schulung: Ihr Team betreibt die Kette selbst — oder wir tun es im Managed-Modell.
Vorgehen
Automatisierung folgt dem Risiko und dem wirtschaftlichen Nutzen — in genau dieser Reihenfolge.
Wie belastbar sind Inventar, Standards und Change-Prozess? Wo lohnt Automatisierung zuerst?
NetBox aufbauen und befüllen; die Wahrheit wandert aus Tabellen und Köpfen in ein geprüftes Modell.
Ein wiederkehrender Change wird vollständig automatisiert — mit Tests, Freigabe und Rollback.
Weitere Use Cases, Peer-Review-Pflicht, getrennte Umgebungen und vollständige Protokollierung.
Verständlich erklärt
Source of Truth, Configuration as Code und getestete Changes: die Grundlagen eines nachvollziehbaren Netzbetriebs, mit klaren Datenquellen und Freigaben.
Bei wiederkehrenden Änderungen werden dieselben Vorgaben oft auf vielen Geräten umgesetzt. Mit Templates und Ansible lässt sich dieser Ablauf standardisieren. Das reduziert Handarbeit, kann aber auch einen Fehler vervielfältigen. Deshalb gehören geprüfte Eingangsdaten, ein begrenzter Wirkungsbereich und Vorher-Nachher-Tests von Anfang an dazu. Wir beginnen mit einer konkreten Aufgabe, deren Nutzen und Risiken sich bewerten lassen.
NetBox kann den beabsichtigten Zustand von Standorten, Geräten, VLANs und IP-Adressen dokumentieren. Wir definieren Datenhoheit, Pflege und Freigaben, bevor Konfigurationen daraus erzeugt werden. Ein geänderter Datensatz löst nicht automatisch einen Netzchange aus. Beobachteter Zustand und Sollzustand werden getrennt abgeglichen; Widersprüche brauchen eine Entscheidung.
Mit pyATS/Genie oder passenden alternativen Prüfungen lassen sich ausgewählte Netzfunktionen vor und nach einem Change vergleichen. Welche Routen, Nachbarschaften oder Verbindungen erwartet werden, wird ausdrücklich festgelegt. Fehlende Daten sind kein Erfolg, und ein grüner Test beweist nicht die Funktion jeder Anwendung. Die Abnahme verbindet Messwerte mit den vereinbarten Erwartungen.
Alle Vorlagen und Konfigurationen liegen versioniert in Git — demselben Werkzeug, mit dem Software-Teams seit Jahrzehnten arbeiten. Zu jeder Änderung ist festgehalten, wer sie wann warum gemacht hat und wie der Stand davor aussah; ein Vier-Augen-Review vor der Freigabe gehört zum Prozess. Für Audits und Zertifizierungen heißt das: Die Nachweise existieren bereits, statt mühsam rekonstruiert zu werden.
Werkzeuge & Plattformen
Dokumentiertes Configlane-Lab · TI-LFA
Im Next-Gen-SP-Core-Lab aktiviert CHG-0026 TI-LFA auf R1–R7. An diesem realen Change zeigen wir, welche Eingaben, Freigaben und Nachweise zusammengehören.
Sieben gerätespezifische Intent-Dateien beschreiben Kandidatenkonfiguration und Prüfbedingungen. Ansible erzeugt den Diff; das Manifest bindet Plan, Git-Commit, Zielhosts und Ausführungs-Image.
Ein getrennter Approver signiert den geprüften Plan. Vor dem seriellen Apply werden Signatur, Scope und Manifest erneut geprüft. Eine Abweichung stoppt die Ausführung.
CHG-0026 weist operative SR-Reparaturpfade auf allen 20 gerichteten Core-Interfaces nach. CHG-0027 trennt anschließend den Link R1–R2; der Ersatzpfad über R3 trägt. CHG-0028 stellt den Link als eigenen Change wieder her.
FAQ
Entscheidend sind Wiederholung, Datenqualität, Risiko und Pflegeaufwand, nicht eine feste Gerätezahl. Wir bewerten einen konkreten Anwendungsfall und starten dort, wo ein nachvollziehbarer Nutzen entsteht. Eine pauschale Amortisationszeit wäre ohne diese Aufnahme geraten.
Nein — sie verlagert deren Arbeit von der Tastatur in die Entscheidung. Freigaben bleiben bei Menschen; die Maschine übernimmt das fehleranfällige Abtippen und Prüfen. Teams gewinnen Zeit für Architektur und Verbesserungen statt für nächtliche Routine-Changes.
Für den Betrieb: nein. Die Kette ist so gebaut, dass Standard-Changes über gepflegte Daten und definierte Abläufe laufen — ohne Code-Kenntnisse. Wer tiefer einsteigen will, bekommt Schulung und Runbooks; alternativ betreiben wir die Kette im Managed-Modell weiter.
Der Kern unserer Praxis: Cisco IOS-XE (Catalyst), NX-OS und die Meraki Dashboard API — grundsätzlich alles mit brauchbarer API oder SSH-Zugang. Ansible und Python sind herstellerneutral; ob sich Ihre Umgebung eignet, klärt das Assessment am Anfang.
Vor dem Change werden Stop-Kriterien, Vor- und Nachprüfungen sowie ein technisch passender Rückfallweg festgelegt. Check Mode und Wiederherstellung hängen von Modul, Gerät und Eingriff ab. Ein fehlgeschlagener Lauf bedeutet daher nicht automatisch, dass jede Änderung rückgängig gemacht werden kann.
Mit dem Assessment: Wir prüfen Inventar, Standards und Change-Prozess und wählen die eine Strecke mit dem besten Verhältnis aus Nutzen und Risiko. Sie läuft zuerst parallel zum gewohnten Vorgehen, bis die Ergebnisse überzeugen — erst dann wird sie der Standard.
Merged, replaced, overridden: Wie Ressourcen-Module aus Kommandos Zustände machen, warum kein Lauf ohne Probelauf mit Diff startet — und welche States ganz ohne Gerät laufen.
5 Min. LesezeitAutomatisierung · MethodeWer automatisiert, braucht eine Instanz, die sagt, was gelten soll. Warum NetBox das Soll hält statt das Ist zu importieren, die Reihenfolge der Befüllung und die Übergabe an Ansible.
8 Min. LesezeitKryptografie · BetriebErst 200, dann 100, ab 2029 47 Tage: Warum die Verkürzung der Zertifikatslaufzeiten vor allem ein Netzbetriebsthema ist — und welche Stellen zuerst auffallen.
6 Min. LesezeitNächster Schritt
Wir starten mit dem Assessment und automatisieren dann die Strecke, die sich zuerst rechnet — nachvollziehbar und mit definierten Kontrollen.
Assessment anfragenAssessment → belastbarer erster Change
