18.8 Fallbeispiel: Wenn Automatisierung im Netzwerk fehlschlägt

Wenn Automatisierung im Netzwerk fehlschlägt, zeigt sich sehr schnell, wie stark moderne Betriebsprozesse von Datenqualität, sauberer Logik, kontrollierten Changes und nachvollziehbarer Fehlersuche abhängen. In stabilen Phasen wirkt Automatisierung oft unspektakulär: Backups laufen, Standards werden ausgerollt, Compliance-Prüfungen liefern Ergebnisse, und Dokumentation aktualisiert sich nahezu nebenbei. Genau deshalb entsteht leicht der Eindruck, dass Automatisierung vor allem Geschwindigkeit und Komfort bringt. In der Praxis zeigt sich ihr eigentlicher Reifegrad aber meist erst dann, wenn etwas schiefläuft. Ein kleines Problem in einem Template, eine falsche Variable im Inventar oder eine ungenaue Zielgruppendefinition kann nicht nur ein Gerät betreffen, sondern viele Systeme gleichzeitig beeinflussen. Für Network Engineers ist es deshalb besonders wertvoll, Fehlschläge nicht nur abstrakt zu betrachten, sondern an einem konkreten Fallbeispiel zu verstehen: Wo lag die Ursache, wie wurde das Problem sichtbar, welche Denkfehler verzögerten die Lösung und welche Lehren ergeben sich daraus für produktionsnahe Netzwerkautomatisierung?

Ausgangssituation des Fallbeispiels

Ein kleines Team mit standardisiertem Branch-Router-Rollout

Das betrachtete Beispiel spielt in einem mittelgroßen Unternehmensnetz mit mehreren Filialstandorten. Das Netzwerkteam arbeitet bereits mit grundlegender Automatisierung. Für Branch-Router existieren standardisierte Konfigurationstemplates, Inventardateien in YAML und ein Ansible-Playbook, mit dem Basisänderungen auf viele Standorte ausgerollt werden. Das Team ist technisch kompetent, aber eher klein besetzt und parallel stark im Tagesbetrieb eingebunden.

• Branch-Router werden über ein gemeinsames Template verwaltet.
• Standortdaten liegen in Inventar- und Variablendateien.
• Rollouts laufen per Ansible auf definierte Gerätegruppen.
• Git wird für Templates, Playbooks und Inventare genutzt.
• Pre-Checks existieren, sind aber eher technisch als fachlich ausgeprägt.

Die Umgebung ist also nicht improvisiert, aber auch nicht maximal abgesichert. Genau das macht das Beispiel realistisch, weil viele produktive Netze in einem ähnlichen Reifegrad arbeiten.

Der geplante Change: Syslog- und NTP-Standard erweitern

Das Team möchte einen Routine-Change umsetzen. Auf allen Branch-Routern sollen ein zusätzlicher Syslog-Host und ein zweiter NTP-Server ergänzt werden. Es handelt sich also scheinbar um eine relativ einfache Standardänderung mit geringem Risiko.

Die gewünschte Zielkonfiguration ist grob:

conf t
ntp server 10.10.10.10
ntp server 10.10.10.11
logging host 10.20.20.20
logging host 10.20.20.21
end
write memory

Weil der Change standardisiert, gut verständlich und bereits auf ähnlichen Plattformen erfolgreich durchgeführt wurde, stuft das Team das Risiko als niedrig ein. Genau an dieser Stelle beginnt der eigentliche Lerneffekt des Fallbeispiels: Der Change wirkt harmlos, entfaltet aber durch einen kleinen Logikfehler deutliche Auswirkungen.

Die technische Vorbereitung des Changes

Änderung am Template und an den Standortdaten

Der zuständige Engineer ergänzt das Branch-Router-Template um den zweiten Syslog-Host und den zusätzlichen NTP-Server. Gleichzeitig passt er eine Variablendatei an, in der standortbezogene Parameter gepflegt werden. Das Template selbst sieht vereinfacht ungefähr so aus:

hostname {{ hostname }}

ntp server {{ ntp_server_1 }}
ntp server {{ ntp_server_2 }}

logging host {{ syslog_server_1 }}
logging host {{ syslog_server_2 }}

In der Variablendatei werden die neuen Werte eingetragen. Der Change wird versioniert, mit Git committed und danach für den Rollout vorbereitet.

Typische Git-Schritte:

git status
git diff
git add templates/branch_router.j2 inventory/branches.yml
git commit -m "Ergaenze zweiten NTP-Server und zweiten Syslog-Host fuer Branch-Router"

Aus Sicht des Engineers ist die Änderung sauber dokumentiert und technisch überschaubar.

Was übersehen wurde

In der Inventardatei existiert für einen Teil der älteren Branch-Router nicht das Feld syslog_server_2, sondern ein historisch abweichender Name aus einer älteren Modellierungsphase. Zusätzlich gibt es eine kleine Gruppe älterer Router, deren Rollenbezeichnung nicht exakt branch_router, sondern branch-router lautet. Diese Inkonsistenz war im Alltag lange unkritisch, weil der bisherige Template-Block nur auf Werte zugriff, die überall vorhanden waren.

Ein vereinfachter problematischer Inventarausschnitt sieht so aus:

devices:
  - name: fra-branch-rtr01
    host: 192.0.2.20
    role: branch_router
    syslog_server_1: 10.20.20.20
    syslog_server_2: 10.20.20.21

  - name: muc-branch-rtr07
    host: 192.0.2.27
    role: branch-router
    syslog_server_1: 10.20.20.20
    syslog_srv_2: 10.20.20.21

Formal ist die Datei nicht kaputt. Fachlich enthält sie aber Inkonsistenzen, die im Rollout relevant werden. Genau das ist typisch für Automatisierungsfehler in produktionsnahen Netzen: Nicht alles ist offensichtlich falsch, aber nicht alles ist sauber standardisiert.

Der Fehlschlag im produktiven Betrieb

Der Rollout startet und meldet nur teilweise Erfolg

Das Ansible-Playbook wird gegen die definierte Branch-Router-Gruppe gestartet. Ein Teil der Geräte nimmt die Änderung korrekt an. Einige Router werden jedoch übersprungen, andere melden Fehler im Template-Rendering, und bei einer kleinen Gruppe wird das Playbook gar nicht ausgeführt, weil sie über die Rollenlogik nicht richtig in die Zielgruppe fallen.

Ein vereinfachtes Playbook-Schema:

---
- name: Standardaenderungen auf Branch-Routern ausrollen
  hosts: branch_routers
  gather_facts: no
  tasks:
    - name: Template ausrollen
      ios_config:
        src: templates/branch_router.j2

Auf den ersten Blick wirkt das wie ein begrenztes Problem. Tatsächlich entsteht aber eine besonders unangenehme Lage: Ein Teil der Infrastruktur ist erfolgreich aktualisiert, ein anderer Teil bleibt auf altem Stand, und die Fehlermeldungen sind nicht auf allen Geräten identisch.

• Einige Router erhalten beide neuen Werte korrekt.
• Einige Router scheitern am fehlenden Variablenfeld.
• Einige Router werden gar nicht als Zielsysteme erkannt.
• Der Change endet also in einem inkonsistenten Gesamtzustand.

Genau solche Teilfehlschläge sind in der Praxis besonders problematisch, weil sie schwieriger zu erkennen sind als ein klarer Vollabbruch.

Die ersten Symptome im Betrieb

Kurz nach dem Rollout meldet das Monitoring an einigen Standorten fehlende Syslog-Events auf dem neuen Collector. Parallel zeigt ein Compliance-Check, dass ein Teil der Branch-Router weiterhin nur einen NTP-Server konfiguriert hat. Zusätzlich fällt bei einer späteren Störung auf, dass sich einige Standorte unterschiedlich verhalten, obwohl sie laut Standard gleich aufgebaut sein sollten.

• Monitoring-Daten sind uneinheitlich.
• Compliance-Reports zeigen inkonsistente Ergebnisse.
• Einige Geräte entsprechen dem neuen Soll-Zustand, andere nicht.
• Das Team erkennt: Der Rollout war nur teilweise erfolgreich.

Das ist der Punkt, an dem aus einem scheinbar kleinen Automatisierungsfehler ein echter Betriebsfall wird.

Die erste Reaktion des Teams

Der erste Denkfehler: Geräteproblem statt Prozessproblem vermuten

Weil einige Router den Change korrekt übernommen haben und andere nicht, geht das Team zunächst von einem gerätespezifischen Problem aus. Die ersten Prüfungen fokussieren sich stark auf die betroffenen Router selbst.

Typische CLI-Checks:

show running-config | include ntp
show running-config | include logging
show version
show logging

Diese Prüfungen zeigen zwar den inkonsistenten Zustand, erklären aber noch nicht die Ursache. Das Team sieht, dass einige Geräte korrekt konfiguriert sind und andere nicht, findet aber zunächst keine eindeutige technische Auffälligkeit an den problematischen Routern.

• Keine Hardwarefehler
• Keine auffälligen CPU- oder Speicherspitzen
• Keine generellen SSH- oder API-Probleme
• Kein offensichtlicher Plattform-Bug

Hier zeigt sich der erste wichtige Lerneffekt: Nicht jede inkonsistente Gerätekonfiguration ist ein Gerätefehler. Gerade in automatisierten Umgebungen muss früh geprüft werden, ob das Problem vor dem Gerät entstanden ist.

Der zweite Denkfehler: Nur den Template-Code prüfen

Nachdem keine klaren Geräteprobleme sichtbar werden, richtet sich der Fokus stark auf das Template. Das Team sucht zunächst nach Fehlern in der Jinja2-Logik.

• Ist eine Bedingung falsch?
• Wird ein Wert nicht korrekt gerendert?
• Ist die Ausgabe für bestimmte Plattformen anders?

Das Template selbst erweist sich jedoch als formal korrekt. In Testdaten mit vollständig gepflegten Variablen erzeugt es genau die gewünschte Konfiguration. Das Problem liegt also weder eindeutig im Gerät noch direkt im Template. Erst an diesem Punkt beginnt die Analyse, systematischer zu werden.

Die strukturierte Fehlersuche

Schritt eins: Zielgruppe und Betroffenheit präzise eingrenzen

Das Team wechselt von symptomorientierter Suche zu einer strukturierteren Methode. Zuerst wird geprüft, welche Geräte genau betroffen sind und ob es ein Muster gibt.

• Sind nur ältere Router betroffen?
• Gibt es eine standortbezogene Häufung?
• Sind nur bestimmte Rollenkennzeichnungen beteiligt?
• Hängen die Probleme mit derselben Inventarstruktur zusammen?

Diese Analyse zeigt schnell ein auffälliges Muster:

• Router mit sauber gepflegter branch_router-Rolle funktionieren.
• Router mit abweichender Rollenbezeichnung werden gar nicht adressiert.
• Router mit historisch abweichendem Variablennamen scheitern beim Rendering.

Damit ist klar: Das Problem ist kein zufälliger Gerätefehler, sondern ein Logik- und Datenproblem in der Automatisierungskette.

Schritt zwei: Repository und letzte Änderungen prüfen

Nun wird die Git-Historie und der genaue Inhalt der Änderung untersucht.

Typische Befehle:

git log --oneline
git diff
git show

Dabei wird nachvollzogen:

• Welche Dateien wurden geändert?
• Wann trat das Problem erstmals auf?
• Welche Variablen setzt das neue Template voraus?
• Welche Inventardaten weichen vom erwarteten Modell ab?

Hier zeigt sich der eigentliche Kern des Problems: Das neue Template setzt stillschweigend voraus, dass alle Branch-Router dieselben Feldnamen und dieselbe Rollenbezeichnung verwenden. Diese Annahme war in der Realität falsch.

Die eigentliche Ursache

Ein kombinierter Logik- und Datenkonsistenzfehler

Die Ursache des Fehlschlags ist kein einzelner Syntaxfehler, sondern eine Kombination aus zwei Schwächen:

• Das Template und der Rollout gehen von einer streng konsistenten Datenbasis aus.
• Die Inventardaten sind historisch gewachsen und nicht vollständig vereinheitlicht.

Genauer gesagt:

• Ein Teil der Geräte wird wegen abweichender Rollenbezeichnung nicht korrekt adressiert.
• Ein anderer Teil scheitert, weil ein Pflichtfeld unter einem alten Namen gespeichert ist.
• Pre-Checks haben nur Verbindung und Erreichbarkeit geprüft, aber keine fachliche Datenvalidierung durchgeführt.

Das ist ein typischer produktionsnaher Automatisierungsfehler: Nicht das Werkzeug ist grundsätzlich falsch, sondern die Annahme, dass die Datenlandschaft schon sauber genug sei.

Warum der Fehler vorher nicht aufgefallen ist

Der Fehler blieb zunächst unsichtbar, weil frühere Rollouts nie auf das neue Feld syslog_server_2 zugreifen mussten. Die historische Inkonsistenz war also latent vorhanden, wurde aber erst mit der neuen Änderung wirksam.

• Alte Logik benötigte nur syslog_server_1.
• Das neue Template macht einen zweiten Wert verpflichtend.
• Die Datenbasis war also schon vorher uneinheitlich, aber nicht sichtbar fehlerhaft.

Das ist eine der wichtigsten Lehren des Falls: Viele Automatisierungsfehler entstehen nicht neu, sondern machen bestehende Datenqualitätsprobleme erst sichtbar.

Die Behebung des Problems

Schrittweise Reparatur statt hektischer Komplettumbau

Das Team entscheidet sich bewusst gegen einen schnellen zweiten Vollrollout und repariert das Problem in mehreren kontrollierten Schritten.

• Die betroffenen Inventareinträge werden vereinheitlicht.
• Die Rollenbezeichnung wird standardisiert.
• Fehlende Pflichtfelder werden ergänzt.
• Das Template erhält defensivere Prüfungen.
• Ein kleiner Testlauf erfolgt auf einer Pilotgruppe.

Ein robusterer Python- oder Template-Ansatz könnte später etwa Pflichtfelder vorab prüfen, statt sie still vorauszusetzen.

Ein vereinfachtes Prüfprinzip wäre:

if not device.get("syslog_server_2"):
    raise ValueError("Pflichtfeld syslog_server_2 fehlt")

So wird aus einem schleichenden Inkonsistenzproblem eine klare, früh erkennbare Fehlermeldung.

Verbesserte Verifikation vor erneutem Rollout

Vor dem zweiten Rollout baut das Team zusätzliche Prüfungen ein. Diese konzentrieren sich nicht nur auf Erreichbarkeit, sondern auch auf fachliche Datenkonsistenz.

• Existieren alle Pflichtfelder?
• Sind Rollenbezeichnungen konsistent?
• Werden alle Zielgeräte durch den Filter korrekt erfasst?
• Lässt sich das Template für alle Geräte in der Gruppe erfolgreich rendern?

Erst nach dieser Validierung wird erneut ausgerollt. Der zweite Rollout verläuft dann erfolgreich und konsistent.

Was das Team aus dem Fehlschlag gelernt hat

Automatisierung scheitert oft an Annahmen, nicht an Tools

Eine der wichtigsten Erkenntnisse aus dem Fall ist, dass nicht Ansible, Jinja2 oder Git das Problem waren. Der eigentliche Fehler lag in einer unausgesprochenen Annahme: dass alle Branch-Router bereits nach einem vollständig einheitlichen Datenmodell verwaltet würden.

• Das Tool tat genau das, was seine Logik vorgab.
• Die Logik ging von einer Datenkonsistenz aus, die real nicht existierte.
• Der Fehlschlag war also ein Reifegradproblem, kein Produktproblem.

Das ist eine sehr typische Situation in realen Netzwerken und deshalb besonders lehrreich.

Pre-Checks müssen fachlich sein, nicht nur technisch

Vor dem Vorfall waren Pre-Checks vor allem auf Verbindung, Login und Basiszugriff fokussiert. Nach dem Vorfall wird klar: In automatisierten Umgebungen reichen rein technische Vorprüfungen nicht aus.

• Erreichbarkeit ist nur die erste Hürde.
• Datenmodell und Pflichtfelder müssen genauso geprüft werden.
• Targeting und Rollenzuordnung müssen verifiziert werden.
• Template-Rendering für die gesamte Zielgruppe sollte vorab testbar sein.

Das Team erweitert deshalb seine Change-Vorbereitung um fachliche Datenvalidierung.

Teilweise erfolgreiche Rollouts sind besonders gefährlich

Ein vollständiger Fehlschlag ist oft leichter sichtbar und einfacher zu stoppen. Teilweise erfolgreiche Rollouts erzeugen dagegen inkonsistente Zustände, die sich erst später operativ bemerkbar machen.

• Ein Teil der Geräte ist korrekt.
• Ein Teil bleibt alt.
• Ein Teil bricht mit Fehlern ab.
• Die Infrastruktur verliert ihre Standardkonsistenz.

Genau deshalb braucht Automatisierung nicht nur Erfolgsmeldungen, sondern klare Vollständigkeits- und Konsistenzprüfungen.

Welche Best Practices aus dem Fall ableitbar sind

Datenqualität als produktive Abhängigkeit behandeln

Inventare, Variablen und Rollenmodelle sind keine Nebensache. Sie sind produktionsrelevante Grundlagen. Kleine Inkonsistenzen können lange unbemerkt bleiben und erst bei einer bestimmten Änderung kritisch werden.

• Feldnamen standardisieren
• Rollenbegriffe vereinheitlichen
• Pflichtfelder definieren
• Altlasten aktiv bereinigen

Templates und Playbooks defensiver bauen

Ein robustes Template sollte nicht stillschweigend von vollständigen Daten ausgehen, wenn diese Annahme in der Praxis nicht sicher ist. Fehler müssen früh und klar sichtbar werden.

• Fehlende Variablen früh erkennen
• Leere Werte explizit behandeln
• Zielgruppen vorab kontrollieren
• Gerenderte Ergebnisse vor Rollout prüfen

Änderungen immer gegen die reale Zielgruppe testen

Tests mit Beispielwerten sind hilfreich, reichen aber nicht immer aus. In diesem Fall funktionierte das Template in idealisierten Testdaten, scheiterte aber an historischen Inkonsistenzen der echten Zielgruppe.

• Mit echten Inventardaten testen
• Pilotgruppen bewusst wählen
• Teilgruppen mit historischen Sonderfällen einbeziehen

Best Practices aus dem Fallbeispiel

• Vor jedem Rollout nicht nur Erreichbarkeit, sondern auch Datenqualität und Pflichtfelder prüfen.
• Rollenbezeichnungen, Feldnamen und Inventarstrukturen konsequent standardisieren.
• Templates und Playbooks defensiv bauen und fehlende Daten früh abfangen.
• Rollouts nicht nur auf Erfolg einzelner Geräte, sondern auf Vollständigkeit und Konsistenz bewerten.
• Git-Historie und Diffs früh in die Fehlersuche einbeziehen.
• Teilweise erfolgreiche Rollouts als ernstes Risiko behandeln.
• Mit realistischen Zielgruppendaten testen und nicht nur mit idealisierten Beispielen.
• Pre-Checks um fachliche Validierung ergänzen.
• Automatisierungsfehler nicht vorschnell als Geräteprobleme interpretieren.
• Nach jedem Fehlschlag nicht nur korrigieren, sondern die zugrunde liegende Annahme hinterfragen.

Dieses Fallbeispiel zeigt sehr deutlich, dass Automatisierung im Netzwerk selten an spektakulären technischen Einzelproblemen scheitert, sondern oft an kleinen Inkonsistenzen zwischen Datenmodell, Logik und realer Umgebung. Genau deshalb ist der wichtigste Lerneffekt nicht nur, wie der konkrete Fehler behoben wurde, sondern wie das Team danach seine Arbeitsweise verändert hat: weg von der Annahme idealer Daten, hin zu systematischer Validierung, defensiverer Logik und präziserem Verständnis dafür, dass Automatisierung nur so stabil ist wie die Qualität der zugrunde liegenden Modelle und Prozesse.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.