Site icon bintorosoft.com

18.8 Fallbeispiel: Wenn Automatisierung im Netzwerk fehlschlägt

bintorosoft@gmail.com

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.

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.

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.

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.

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.

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.

Diese Analyse zeigt schnell ein auffälliges Muster:

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:

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:

Genauer gesagt:

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.

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.

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.

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 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.

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.

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.

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.

Ä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.

Best Practices aus dem Fallbeispiel

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:

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

Exit mobile version