“It worked before”: Konfig-Drift und Diff-Analysen im Netzwerk

„It worked before“ ist einer der häufigsten und zugleich unerquicklichsten Sätze im Netzwerkbetrieb. Er bedeutet meist nicht, dass das Netzwerk „plötzlich“ kaputt gegangen ist, sondern dass sich der Normalzustand schleichend verändert hat: Konfig-Drift. Darunter versteht man Abweichungen zwischen dem erwarteten (dokumentierten oder versionierten) Konfigurationszustand und dem tatsächlich laufenden Zustand auf Geräten. Diese Abweichungen entstehen durch Hotfixes in der Nacht, manuelle Anpassungen am Switchport, unvollständige Rollouts, unterschiedliche Template-Versionen, Geräteersatz ohne sauberes Golden-Config, oder auch durch automatische Systeme, die mehr verändern als gedacht. Das Ergebnis sind Störungen, die schwer reproduzierbar sind: ein Standort funktioniert, ein anderer nicht; ein VLAN ist nur auf einem Trunk „vergessen“ worden; BGP-Policies sind auf einem Router leicht anders; QoS greift nur in einer Zone; oder eine Firewall-Regel ist in der falschen Reihenfolge. Professionelles Troubleshooting bei „It worked before“ beginnt daher nicht mit Packet Captures, sondern mit Diff-Analysen: Was hat sich geändert? Wo ist der Drift? Und welche Abweichung ist wirklich relevant für das Fehlerbild? Dieser Artikel zeigt, wie Sie Konfig-Drift systematisch erkennen, wie Sie Diffs im Netzwerk richtig interpretieren und wie Sie Drift-Prävention so aufbauen, dass aus „It worked before“ wieder ein schneller, evidenzbasierter Debugging-Prozess wird.

Konfig-Drift im Netzwerk: Was genau driftet eigentlich?

Konfig-Drift ist nicht nur „jemand hat etwas geändert“. In der Praxis gibt es mehrere Drift-Typen, die sich unterschiedlich auswirken und unterschiedlich gut detektieren lassen.

• Manuelle Drift: Änderungen per CLI/GUI direkt am Gerät (z. B. Trunk-Liste, ACL, Routing-Policy), ohne dass das zentrale Template angepasst wurde.
• Automationsdrift: Ein Automationsjob rollt eine neue Version aus, aber nicht überall oder mit unerwarteten Nebenwirkungen (z. B. Jinja-Template-Änderung, Variablen-Fehler, Conditional-Logic).
• State-Drift: Der Zustand weicht ab, obwohl die Konfig gleich scheint (z. B. Policy installiert, aber TCAM voll; BGP up, aber RIB leer; NAT-Port-Exhaustion). Hier hilft „State Diff“ zusätzlich zum Config Diff.
• Version-/Feature-Drift: Unterschiedliche Software-Versionen oder Feature-Flags führen zu anderem Verhalten bei gleicher Konfig (z. B. Bugfixes, Default-Änderungen).
• Shadow-Config: Ein zentraler Controller (WLAN, SD-WAN, Fabric) setzt intern Konfigurationen, die in klassischer CLI nicht 1:1 sichtbar sind.

Wichtig für die Fehlersuche: Nicht jeder Drift ist „falsch“. Manche Abweichungen sind bewusst (Ausnahmen), manche sind technisch irrelevant. Der Schlüssel ist, Drift nach Risiko und Relevanz zu priorisieren.

Warum „Diff“ im Netzwerk anders ist als „Diff“ im Code

In Softwareprojekten ist Diff meist eine reine Textänderung. In Netzwerken ist Diff mehrdimensional: Eine kleine Textänderung kann massive Auswirkungen haben (z. B. ACL-Reihenfolge), während große Textdifferenzen im Ergebnis funktional identisch sein können (z. B. Reihenfolge von statischen Einträgen ohne Semantik). Außerdem existieren unterschiedliche „Views“ auf Konfiguration:

• Running vs. Startup: Was läuft gerade, und was überlebt einen Reboot?
• Intended vs. Applied: Was sollte laut Source of Truth gelten, und was ist tatsächlich angewendet?
• Rendered vs. Device-Native: Automationssysteme generieren Konfig; das Gerät speichert sie ggf. normalisiert oder mit Defaults.
• Candidate Config (NETCONF): In modellgetriebenen Umgebungen gibt es Transaktionsmodelle statt „Zeile geändert“.

Wenn Sie Diffs beurteilen, müssen Sie daher semantisch denken: Welche Policy-Entscheidung ändert sich? Welcher Traffic ist betroffen? Welche Geräte sind im Pfad? Nur so wird aus Diff eine RCA-Hypothese.

Die häufigsten „It worked before“-Drift-Fälle nach Praxisrelevanz

Bestimmte Drift-Kategorien tauchen in Incidents immer wieder auf. Wer diese Muster kennt, kann Diffs schneller auf „High Signal“ scannen.

• VLAN/Trunk Drift: Allowed VLANs fehlen auf einem Uplink, Native VLAN mismatch, VLAN existiert nicht auf einem Switch.
• ACL/Firewall Drift: Regelreihenfolge geändert, Objektgruppen erweitert, NAT-Regel verschoben, ICMP/PMTUD aus Versehen blockiert.
• Routing Policy Drift: Prefix-Listen, Route-Maps, Communities, LocalPref – oft nur ein einzelner Router abweichend.
• QoS Drift: DSCP Trust fehlt auf einem Access-Edge, Policer anders dimensioniert, Queue-Mapping abweichend.
• MTU/MSS Drift: Jumbo auf einem Segment aktiv, aber nicht auf allen Links; Tunnel-Overhead nicht berücksichtigt.
• AAA/NAC Drift: 802.1X/MAB-Profile oder RADIUS-Serverliste abweichend, VLAN Assignment driftet.
• MLAG/vPC Drift: Consistency-Parameter, Peer-Link VLAN-Liste, LACP-Settings – führt zu Intermittency statt Hard Down.

Methodik: Drift-Debugging als forensischer Prozess

Wenn Sie vermuten, dass „früher ging es“, ist die erste Aufgabe, einen sauberen Referenzpunkt zu definieren. Ohne Referenz wird jede Diff-Analyse beliebig.

Referenzpunkte, die in der Praxis funktionieren

• Letzte bekannte gute Konfiguration: Snapshot aus Config-Repository oder Backup-System.
• Golden Config / Template: Das erwartete Profil für Geräteklasse und Rolle (z. B. Access-Switch, Leaf, Edge-Router).
• Peer-Vergleich: Vergleich mit einem „gleichen“ Gerät (gleiche Rolle, gleicher Standorttyp), das nicht betroffen ist.
• Change-Fenster: Zeitliche Eingrenzung: Was wurde seit t0 geändert (auch indirekt durch Automation)?

Je nach Umgebung ist der Peer-Vergleich der schnellste Einstieg: „Warum funktioniert Rack A, aber Rack B nicht?“ Ein Diff zwischen zwei fast identischen Leafs liefert oft sofort die Ursache.

Diff-Analysen richtig lesen: Von Textdifferenz zu Wirkung

Ein effektiver Diff-Review folgt einer festen Reihenfolge: zuerst die Bereiche mit hoher Wirkungswahrscheinlichkeit, dann Details. Das vermeidet, dass Sie sich in harmlosen Abweichungen verlieren.

High-Signal Bereiche im Diff

• Interface-Blocks: Trunk/Access Mode, VLAN Lists, MTU, Speed/Duplex, LACP, STP Guard, Port Security.
• Routing-Policies: Prefix-Lists, Route-Maps, Policy-Statements, BGP Neighbors, Max-Prefix, RPKI/ROV Flags.
• Security-Policies: ACLs, Firewall Rules, NAT, Zone-Policies, uRPF, ICMP Handling.
• QoS-Policies: Class-Maps, Policy-Maps, DSCP Trust, Shaping/Policing.
• System/Control: NTP, SNMP, Syslog, Management VRF, AAA, TACACS/RADIUS, CoPP.

Low-Signal Bereiche, die oft ablenken

• Banner, Kommentare, Reihenfolgen ohne Semantik: kann groß aussehen, ist aber meist irrelevant.
• Automatisch normalisierte Defaults: Manche Geräte schreiben Defaults in running-config, andere nicht.
• Änderungen ohne Pfadrelevanz: Eine QoS-Klasse kann geändert sein, aber wenn der Link nicht Engpass ist, ist sie nicht ursächlich.

State Diff: Warum Konfig gleich sein kann, aber Verhalten abweicht

Wenn Diffs „nichts“ zeigen, ist das nicht das Ende. Häufig ist die Konfiguration zwar gleich, aber der Zustand driftet. Beispiele:

• TCAM/Hardware-Tabellen voll: ACL oder QoS wird teilweise nicht installiert; Ergebnis: Traffic passt nicht wie erwartet.
• Control Plane Overload: Routing-Adjacencies flappen; Konfig ist ok, CPU nicht.
• ARP/ND Cache Anomalien: Duplicate IP, ARP flux, fehlerhafte Cache-Timeouts erzeugen intermittierende Erreichbarkeit.
• NAT-Port-Auslastung: SNAT Exhaustion erzeugt Timeouts, ohne dass die Policy falsch ist.

Für Drift-Debugging bedeutet das: Ergänzen Sie Config Diffs durch State Snapshots (Interface Counter, Routing Tables, Session Tables, Hardware Programming Status). Erst die Kombination liefert eine belastbare Erklärung.

Werkzeugkette für Konfig-Drift: Von Backup bis Source of Truth

Drift wird beherrschbar, wenn Sie Konfigurationen versionieren und automatisiert vergleichen. Dafür gibt es bewährte Bausteine, die sich kombinieren lassen.

• Versionskontrolle: Git als Basis für nachvollziehbare Änderungen, Reviews und Rollbacks. Einstieg: Git Dokumentation.
• Config-Backup & Diff: Tools wie Oxidized oder RANCID sammeln Konfigs regelmäßig und erzeugen Diffs.
• Automationsframeworks: Ansible (Ansible Docs) oder Nornir (Nornir Docs) für konsistente Rollouts.
• Programmatic Abstraction: NAPALM (NAPALM Docs) für einheitliche Get/Config-Operationen über Vendor-Grenzen hinweg.
• Model-driven Networking: NETCONF/YANG für transaktionale Konfig und strukturierte Diffs: RFC 6241 (NETCONF) und Überblick zu YANG: RFC 7950.
• Network Verification: Batfish hilft, die Auswirkung von Konfigänderungen analytisch zu prüfen (Batfish), bevor sie live gehen.

Wichtig: Die Tool-Auswahl ist sekundär. Entscheidend ist, dass Sie eine „Quelle der Wahrheit“ etablieren und Abweichungen automatisch sichtbar machen.

Diff-Strategien: Wie Sie aus Diffs schnelle Entscheidungen ableiten

Im Incident brauchen Sie schnelle, riskobewusste Entscheidungen: Rollback, Fix Forward, temporäre Ausnahme oder weiter messen. Diffs helfen dabei, wenn Sie sie strukturiert interpretieren.

• Diff → Hypothese: „VLAN 120 fehlt auf Trunk X“ wird zur Hypothese „DHCP in VLAN 120 erreicht Gateway nicht“.
• Hypothese → Test: Minimaler Test (z. B. VLAN temporär erlauben, Route-map match counter prüfen, QoS class counter ansehen).
• Test → Entscheidung: Wenn Impact sofort verschwindet, ist die Ursache stark bestätigt; dann sauber fixen und dokumentieren.

Besonders wirksam ist „Counter-driven Debugging“: Viele Policies haben Match-Counter (ACL hits, route-map matches, class-map counters). Wenn sich Diffs in Countern niederschlagen, ist die Beweiskette sehr robust.

„Diff Noise“ reduzieren: Normalisierung und semantische Diffs

In großen Umgebungen sind Diffs schnell unübersichtlich. Zwei Techniken helfen, Signal vom Rauschen zu trennen:

• Konfig-Normalisierung: Sortieren von Listen, Entfernen bekannter Defaults, Vereinheitlichen von Whitespace, um echte Änderungen sichtbar zu machen.
• Semantische Diffs: Statt Textzeilen zu vergleichen, vergleichen Sie strukturierte Daten (YANG/JSON) oder extrahierte Facts (z. B. „Allowed VLANs = {10,20,30}“).

Model-driven Ansätze (NETCONF/YANG, OpenConfig) eignen sich besonders gut für semantische Diffs, weil sie Konfiguration als Datenmodell darstellen. Einstieg in OpenConfig: OpenConfig.

Konfig-Drift verhindern: Prozesse, nicht nur Tools

Viele Organisationen installieren ein Backup-Tool und wundern sich, warum Drift bleibt. Der Grund: Drift ist auch ein Prozessproblem. Prävention bedeutet, dass Sie definieren, welche Änderungen „legal“ sind und wie Ausnahmen behandelt werden.

• Change-Pfade definieren: Änderungen nur über Git/Automation, nicht per „Quick CLI“, außer im dokumentierten Notfall.
• Break-glass Regeln: Notfall-CLI ist erlaubt, aber muss innerhalb von X Stunden zurück in Source of Truth gemerged werden.
• Drift-Alerts: Automatische Benachrichtigung bei Abweichungen in High-Signal Bereichen (ACL, Routing, VLAN, MTU, QoS).
• Golden Config & Compliance: Geräte werden kontinuierlich gegen Golden Profiles geprüft.
• Staged Rollouts: Kleine Pilotgruppe, dann breite Ausrollung; Drift fällt früh auf.

Runbook: „It worked before“ in 15 Minuten in eine RCA-Hypothese verwandeln

• Minute 0–3: Zeitfenster festlegen (wann ging es zuletzt?), Scope bestimmen (welche Geräte/Standorte/Segmente). Einen funktionierenden Peer als Referenz identifizieren.
• Minute 3–6: Konfig-Snapshots ziehen (betroffen vs. Referenz) und High-Signal Diff scannen: Interfaces/VLAN/MTU, Routing-Policies, ACL/NAT, QoS.
• Minute 6–9: Diff in eine Hypothese übersetzen und minimal testen: Match-Counter, route-map hits, ACL hits, VLAN operational state, next-hop set.
• Minute 9–12: Wenn kein Config-Drift sichtbar: State Diff prüfen (TCAM, CPU, sessions, drops, adjacency health). Zeitkorrelation zu Events herstellen.
• Minute 12–15: Entscheidung: gezielter Fix Forward oder Rollback, mit minimalem Blast Radius. Danach Verifikation und Dokumentation des Drift-Ursprungs.

Weiterführende Quellen

• Git Dokumentation für Versionskontrolle, Reviews und saubere Change-Historie
• Oxidized und RANCID für automatisierte Config-Backups und Diff-Historien
• Ansible Dokumentation und Nornir Dokumentation für reproduzierbare Netzwerkautomation
• NAPALM für vendorübergreifende Abfragen und Konfig-Operationen
• RFC 6241 (NETCONF) und RFC 7950 (YANG) für modellgetriebene Konfiguration und strukturierte Diffs
• OpenConfig als Ansatz für herstellerneutrale Datenmodelle und semantische Konfigvergleiche
• Batfish für Pre-Change Validierung und Analyse von Konfigauswirkungen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.