Netzwerk
Der Soll-Zustand gehört ins Repository, nicht in einen Kopf.
Netze, die per CLI von Hand gepflegt werden, driften, und ihr Wissen hängt an Personen. Wir machen die Konfiguration zu Code: NetBox als Source of Truth, Ansible für den Rollout, Git für jeden Change. Das Ergebnis ist ein Netz, dessen Soll-Zustand sichtbar, prüfbar und reproduzierbar ist.
Dokumentation, die stimmt
- Soll-Zustand liegt im Repository, nicht im Kopf
- Audits werden ruhiger statt hektisch
Änderungen unter Kontrolle
- Jeder Change als prüfbarer Pull Request
- Drift wird erkannt statt zufällig entdeckt
Kein Wissensverlust
- Übergaben ohne Blackbox
- Filialen konsistent statt handgepflegt
Selbst-Check
Wann Handarbeit am Netz zum Risiko wird.
Konfiguration entsteht per CLI und driftet auseinander? Daran merken Sie, wann Automation trägt.
- Konfigurationen entstehen per CLI und weichen über die Zeit voneinander ab.
- Die Dokumentation hinkt der Realität immer hinterher.
- Viele Standorte sollen gleich konfiguriert sein, sind es aber nicht.
- Beim Weggang einzelner Admins droht Wissensverlust.
- Audits verlangen eine nachvollziehbare Change-Historie.
Lösungsansätze
Drei Bausteine für ein Netz als Code.
Source of Truth, automatisierter Rollout und ein Review-Workflow greifen ineinander. Wir starten mit dem Kern und bauen aus, wo es sich lohnt.
Source of Truth (NetBox)
IPAM, Geräte-Inventar, Verkabelung, Circuits und Topologie als einzige führende Quelle für den Soll-Zustand.
Config-Rollout (Ansible)
Playbooks lesen aus der Source of Truth und rollen den Soll-Zustand auf Switches, Router und Firewalls aus.
Git & Review-Workflow
Jeder Change läuft als Pull Request durch Git und ist prüfbar, bevor er produktiv geht.
Weitere Bausteine
Automation wächst mit dem Bedarf, nicht ins Blaue.
IPAM & DCIM
Adressen, Geräte, Racks und Verkabelung an einer Stelle gepflegt.
Drift-Detection
Ist-Konfiguration der Geräte automatisiert holen und gegen den Soll-Zustand diffen. Werkzeuge wie Batfish helfen zusätzlich beim Snapshot-Vergleich (Golden Config vs. aktuell) und bei der Validierung vor dem nächsten Rollout.
Config-Backup & Rollback
Jede Änderung erzeugt automatisch ein versioniertes Konfig-Backup. Ein getesteter Rollback-Pfad stellt sicher, dass ein fehlerhafter Rollout umkehrbar bleibt. Open-Source-Optionen: Oxidized, Nautobot Golden Config.
Secrets-Management
Geräte-Credentials gehören nicht ins Repository. Ansible Vault deckt den dateibasierten Einstieg ab; HashiCorp Vault ermöglicht dynamische, kurzlebige Credentials mit Rotation und Audit-Trail, was für auditierbare privilegierte Zugriffe relevant ist.
Orchestrierung & RBAC
Ansible allein kennt kein RBAC, kein Scheduling und kein zentrales Audit-Log. Eine Orchestrierungsebene wie Semaphore (aktiv gepflegt, ohne Kubernetes-Abhängigkeit) schließt diese Lücke und macht Playbook-Ausführungen nachvollziehbar.
Nautobot für Workflows
Erweiterte Workflows und Plugins, wo NetBox an Grenzen stößt.
CI für Netzwerk
Tests und Validierung vor dem Ausrollen, nicht erst danach. Containerlab ermöglicht container-basierte Testumgebungen mit echten Netzwerk-Betriebssystemen in CI-Pipelines.
Templating
Konsistente Konfiguration aus Vorlagen statt Copy-Paste.
Compliance-Reports
Automatisierte Nachweise über die Soll-Konformität der Geräte.
Zero-Touch Provisioning
Neue Geräte bootstrappen sich beim ersten Start automatisch: DHCP verweist auf den Config-Server, der die Basiskonfiguration liefert; Ansible übernimmt die Feinkonfiguration. Relevant bei Filialrollouts oder Massen-Deployments.
Event-Driven Automation
Auf Events wie Monitoring-Alarme oder Webhooks automatisch mit definierten Regeln reagieren, zum Beispiel als Auto-Remediation bei erkanntem Drift. Das setzt eine stabile Automatisierungs-Grundlage voraus und ist eher der nächste Reifegrad als ein Einstiegsbaustein.
Vorgehen
Von der CLI-Handarbeit zur Source of Truth.
Source of Truth aufbauen
NetBox mit IPAM, Inventar, Verkabelung und Topologie als führende Quelle füllen.
Geräte anbinden
Switches, Router und Firewalls an die Automatisierung koppeln.
Playbooks, Templates & Backup
Soll-Konfiguration als Code abbilden, versionieren und mit automatisierten Config-Backups absichern. Rollback-Pfade werden von Anfang an mitgeplant.
Git-Workflow etablieren
Pull-Request-Review und Freigabe vor Produktiv einführen.
Drift & Reports
Abweichungen automatisiert erkennen und Compliance-Reports erzeugen.
Source of Truth aufbauen
NetBox mit IPAM, Inventar, Verkabelung und Topologie als führende Quelle füllen.
Geräte anbinden
Switches, Router und Firewalls an die Automatisierung koppeln.
Playbooks, Templates & Backup
Soll-Konfiguration als Code abbilden, versionieren und mit automatisierten Config-Backups absichern. Rollback-Pfade werden von Anfang an mitgeplant.
Git-Workflow etablieren
Pull-Request-Review und Freigabe vor Produktiv einführen.
Drift & Reports
Abweichungen automatisiert erkennen und Compliance-Reports erzeugen.
Technische Bausteine
Womit wir Netze automatisieren.
Eine Auswahl der Bausteine, die wir zum Beispiel einsetzen.
Source of Truth
Automatisierung
Versionierung & CI
Validierung
Geräte
NetBox-API
Geräte-Schnittstellen
Sicherheit & Betrieb
Aus der Praxis
Wofür sich Automation besonders lohnt.
Hohe Change-Rate
Datacenter und große Campus-Netze beherrschbar halten.
Filialnetze
Viele Standorte konsistent aus Vorlagen ausrollen.
Audit-Readiness
Nachvollziehbare Change-Historie für Prüfungen.
Team-Übergabe
Wissen liegt im Repository, nicht bei Einzelpersonen.
Migrationsprojekte
Soll-Zustand sauber planen und reproduzierbar ausrollen.
Bevor die Doku wieder hinterherhinkt
Fragen zu Netzwerk-Automation.
Antworten auf typische Fragen zu Aufwand, Multi-Vendor-Unterstützung, Einstieg, Drift-Erkennung, Secrets-Management und Audit-Nutzen.
Automation besprechenSpätestens ab mehreren Standorten oder einer hohen Änderungsrate deutlich. Aber auch kleinere Netze profitieren von einer Dokumentation, die stimmt, weil die Konfiguration durch sie hindurchläuft. Wir dimensionieren den Aufwand passend, ohne zu überfrachten.
Nein. Multi-Vendor ist möglich. Wie gut sich ein Gerät anbinden lässt, hängt von den unterstützten Schnittstellen ab. Aktuelle Enterprise-Plattformen von Cisco, Juniper und Arista sprechen NETCONF (RFC 6241) und RESTCONF (RFC 8040) als transaktionale Config-Protokolle sowie YANG-Datenmodelle nach OpenConfig. gNMI ergänzt das vor allem für Streaming-Telemetrie; wo programmierbare Schnittstellen ganz fehlen, bleibt klassisches CLI/SSH. Das prüfen wir pro Plattform und bilden es sauber ab.
Wir starten pragmatisch: NetBox als Source of Truth, Ansible für den Rollout, Git für die Changes. Dieser Kern ist überschaubar und liefert sofort Nutzen. Erweiterungen wie CI, Drift-Detection oder Nautobot kommen erst dann, wenn sie sich lohnen.
Über einen automatisierten Soll-Ist-Vergleich: Die Ist-Konfiguration der Geräte wird regelmäßig abgeholt und gegen den dokumentierten Soll-Zustand gedifft. Abweichungen werden gemeldet, bevor sie zum Problem werden. Batfish kommt dabei als ergänzendes Werkzeug für Snapshot-Vergleiche (Golden Config vs. aktuell) und für die Validierung vor dem nächsten Rollout zum Einsatz, nicht als Hintergrund-Monitor.
Geräte-Credentials gehören nicht in das Repository. Als dateibasierten Einstieg nutzen wir Ansible Vault; für Umgebungen mit höherem Schutzbedarf setzt HashiCorp Vault auf dynamische, kurzlebige Credentials mit Rotation und Audit-Trail. Das ist auch relevant, wenn Sie auditierbare Nachweise über privilegierten Zugriff brauchen.
Eine durchgängige Change-Historie und eine Soll-Dokumentation, die nicht hinterherhinkt. Prüfer bekommen nachvollziehbar, wer wann was geändert hat und wie der Soll-Zustand aussieht. Das macht Audits ruhiger und schneller.
Der nächste Schritt
Klären wir, wie Ihr Netz zu Code wird.
Wir bauen eine Source of Truth, koppeln die Geräte an und etablieren einen Git-Workflow, mit dem Änderungen prüfbar und der Soll-Zustand reproduzierbar werden.