Backbone-Change-Window-Checkliste: Pre-Check & Post-Check L1–L3

Eine Backbone-Change-Window-Checkliste mit Pre-Check & Post-Check für L1–L3 ist eines der wirksamsten Werkzeuge, um riskante Änderungen im Provider-Backbone kontrolliert durchzuführen. Im ISP/Telco-Umfeld sind Changes selten „lokal“: Ein scheinbar kleiner Eingriff an einem Link-Bundle, einer MPLS-TE-Policy oder einer Routing-Konfiguration kann Traffic-Shifts auslösen, Schutzpfade überlasten, Konvergenzzeiten verlängern oder – im schlimmsten Fall – großflächige Outages verursachen. Genau deshalb braucht jedes Change-Window einen standardisierten Ablauf: erst Stabilität und Kapazitätsreserven prüfen (Pre-Check), dann Änderungen schrittweise und beobachtbar ausrollen, und anschließend systematisch validieren (Post-Check) – entlang der Schichten L1 (Optik/Physik), L2 (Transport/Encapsulation) und L3 (Routing/Reachability). Das Ziel ist nicht Bürokratie, sondern Risiko-Management: Sie wollen Fehler früh erkennen, Blast Radius klein halten, Rollback schnell und sicher machen und die Change-Qualität über Zeit messbar verbessern. Diese Checkliste ist praxistauglich formuliert, damit NOCs sie direkt als Template für Change Requests, War-Rooms oder Maintenance-Pläne nutzen können.

Rahmenbedingungen: Was ein Backbone-Change-Window leisten muss

• Planbarkeit: klare Start-/Endzeiten, definierte Scope-Grenzen (PoP, Ring, RR-Cluster, Peering-Fabric).
• Staging: „klein anfangen“ (ein Link, ein PoP, ein Device-Paar) statt sofort global.
• Rollback-Fähigkeit: Rollback-Plan und „Go/No-Go“-Kriterien sind vor Start festgelegt.
• Observability: Pre/Post-Metriken sind fixiert (gespeicherte Queries, feste Zeitfenster, gleiche Aggregation).
• Ownership: ein Change Owner, ein Reviewer, ein NOC-Lead für Monitoring und Eskalation.

Begriffe und Messdisziplin: Warum Pre- und Post-Checks nur mit Baseline funktionieren

Backbone-Checks sind nur dann aussagekräftig, wenn Sie sie gegen eine Baseline vergleichen. Viele „falsche Alarme“ entstehen, weil Teams normale Schwankungen für Change-Effekte halten. Deshalb ist es sinnvoll, Baselines über mindestens zwei Perspektiven zu definieren: (1) unmittelbarer Vorher-Vergleich (z. B. 30–60 Minuten vor Change) und (2) Referenz aus einer vergleichbaren Zeit (z. B. gleiche Uhrzeit am Vortag oder in der Vorwoche).

• Vorher-Fenster: 30–60 Minuten vor Change Start (bei hohem Traffic auch länger).
• Nachher-Fenster: mindestens 30 Minuten nach Abschluss, bei Routing-Änderungen oft 60–120 Minuten.
• Segmentierung: immer nach Fault Domains (PoP, Ring/SRLG, Linkgruppe, RR-Cluster, Peering).

Change-Window-Vorbereitung: Meta-Checkliste vor den technischen L1–L3 Checks

• Scope dokumentiert: betroffene Geräte/Links/Policies, erwartete Traffic-Shifts, betroffene Fault Domains.
• Risk Assessment: Worst Case (z. B. Link down, TE-Reroute, Route Withdraw) und erwartete Auswirkungen.
• Rollback Plan: klare Schritte, Reihenfolge, Abhängigkeiten, erwartete Rückkehrsignale.
• Kommunikation: NOC-Bridge/Channel, Status-Update-Takt, Stakeholder-Kontakte.
• Freeze-Regel: keine parallelen Changes im gleichen Fault Domain-Bereich.
• Change Guardrails: definierte Abort-Kriterien (z. B. Queue drops > X, Churn > Y, ImpactRate > Z).

Pre-Check L1: Physik/Optik – Stabilität vor jeder Änderung

Layer-1-Checks verhindern, dass Sie einen Change in ein bereits degradierendes Transportsegment hinein starten. Gerade optische Degradation (FEC/BER-Anstieg) kann im Normalbetrieb noch „grün“ aussehen, aber unter Traffic-Shift oder Re-Konvergenz eskalieren.

Pre-Check L1 – Optik/Interface Health

• Link State stabil: keine Flaps in den letzten X Stunden (typisch 6–24h, je Policy).
• Optical Rx/Tx Power: im erwarteten Bereich; auffällige Drift dokumentieren.
• BER/FEC/CRC: keine ansteigenden Fehlertrends; FEC-Korrekturrate stabil.
• Interface Errors: keine ungewöhnlichen RX/TX errors, no overruns.
• Environment: PSU/Temperatur ok, keine aktiven Alarme im PoP.

Pre-Check L1 – Timing/Sync (wenn Telco/Mobile Backhaul relevant)

• PTP/SyncE Status: stable lock, keine holdover alarms.
• Clock Quality: keine Drift- oder Wander-Indikatoren im betroffenen Segment.

Pre-Check L2: Transport/Encapsulation – Kapazität, Queueing, MTU

Layer 2 ist im Backbone oft der Ort, an dem ein Change indirekt wirkt: Traffic verschiebt sich und überlastet Queue- oder Bundle-Kapazität. Deshalb müssen Pre-Checks besonders auf Headroom, Drops und Encapsulation-Konsistenz achten.

Pre-Check L2 – Capacity und Congestion

• Bundle/LACP Health: alle Member up, keine Imbalance zwischen Membern.
• Headroom: Utilization unter definierter Schwelle (z. B. < 70–80% Peak) für betroffene Links und erwartete Schutzpfade.
• Queue Drops: keine erhöhten Drops auf relevanten Interfaces/Queues.
• QoS Profil: bekannt und konsistent; kritische Klassen geschützt (Control-Plane, Voice, ggf. Mobile Signaling).

Pre-Check L2 – MTU/Encapsulation Konsistenz

• MTU End-to-End: passt für MPLS/TE/EVPN/Pseudowire (inkl. Overhead).
• Encapsulation/Tagging: VLAN/QinQ/MPLS Labels erwartungskonform.
• PMTUD/ICMP Policy: nicht ungewollt blockiert (sonst riskieren Sie Blackholes bei MTU-Mismatch).

Pre-Check L2 – MPLS/TE und Protection (falls genutzt)

• LSP State: stabile LSPs, keine Reoptimierungsstürme.
• Protection Paths: verfügbar und mit ausreichender Reserve.
• SRLG Constraints: dokumentiert; Change betrifft nicht gleichzeitig beide Pfade derselben SRLG-Domäne.

Pre-Check L3: Routing – Konvergenz, Churn, Reachability

Layer 3 ist das Herz des Backbone-Betriebs. Pre-Checks müssen sicherstellen, dass das Netz vor dem Change routing-stabil ist. Wenn IGP/BGP bereits churnt, kann eine kleine Änderung eine große Kaskade auslösen.

Pre-Check L3 – IGP Stabilität

• Adjacencies stabil: keine Flaps, keine auffälligen SPF-Läufe.
• Konvergenzzeiten: im Normalbereich, keine „slow converge“-Anzeichen.
• IGP Link Metrics: dokumentiert; geplante Metric-Änderungen sind konsistent.

Pre-Check L3 – BGP Stabilität

• Sessions stabil: keine Reset-Spikes, keepalives ok.
• Route Churn: im Baseline-Bereich; keine Prefix-Limit-Warnungen.
• Policy Health: Filter/Route-Maps/RPKI-Policy (falls genutzt) ohne aktuelle Anomalien.

Pre-Check L3 – Reachability und Pathing

• Health Probes: End-to-End Probes zwischen repräsentativen POPs erfolgreich.
• Peering/Transit: keine Congestion-Warnungen, keine destination-selektiven Ausfälle.
• Anycast Dienste: (DNS/CDN/Edge) Announcement-Set stabil, keine ungewollten Shifts.

Go/No-Go Kriterien: Wann das Change-Window nicht starten darf

• L1 Degradation: steigende BER/FEC, wiederkehrende Link-Flaps, ungeklärte Optikalarme.
• L2 Congestion: bereits erhöhte Queue Drops oder Headroom unter Mindestreserve.
• L3 Instabilität: Route Churn/Adjacency Flaps über Baseline, Prefix-Limit-Warnungen.
• Unklare Ownership: kein Reviewer, kein Monitoring-Lead, kein Rollback Plan.

Change Execution: Schrittweiser Ablauf mit Beobachtung

Die eigentliche Durchführung sollte in Etappen erfolgen, mit kurzen Stabilitätsprüfungen nach jeder Etappe. Das reduziert Blast Radius und macht Rollback leichter.

• Stage 1: Change auf kleiner Scope (ein Device-Paar, ein Link, ein PoP).
• Stage 2: Kurzer Post-Check (Mini) auf L1–L3, dann Ausweitung.
• Stage 3: Change auf restlichen Scope, erneut Mini-Checks.
• Stage 4: Full Post-Check + Monitoring-Fenster.

Post-Check L1: Nach der Änderung – ist die Physik sauber?

Post-Checks beginnen wieder unten: Wenn L1 nach dem Change degradiert, sind alle höheren Metriken nur Folgeeffekte. Ziel ist, neue Fehlertrends sofort zu erkennen.

Post-Check L1 – Optik/Fehlertrends

• Link State: keine neuen Flaps seit Change.
• Rx/Tx Power: im erwarteten Band; keine plötzlichen Sprünge.
• BER/FEC/CRC: keine neuen Anstiege; Fehlerzähler steigen nicht schneller als Baseline.
• Interface Errors: keine neuen RX/TX errors, no overruns.

Post-Check L2: Nach der Änderung – Traffic, Drops, TE

Nach einem Backbone-Change sind L2-Indikatoren oft der früheste Hinweis, ob Traffic sich unerwartet verschoben hat. Besonders wichtig: nicht nur Utilization, sondern Queue Drops und Imbalance.

Post-Check L2 – Capacity und Queueing

• Utilization Shift: erwartete vs. tatsächliche Traffic-Verteilung dokumentieren.
• Queue Drops: Drops dürfen nicht neu ansteigen; wenn doch, sofort Ursachenprüfung (QoS/Hot Link/ECMP).
• Bundle Balance: LACP Member gleichmäßig genutzt (keine Hashing-Hotspots).
• QoS Klassen: keine neue Starvation kritischer Klassen; Control-Plane geschützt.

Post-Check L2 – MPLS/TE Stabilität

• LSP State: stabil, keine Reoptimierungsstürme nach Abschluss.
• Protection: Schutzpfade weiterhin verfügbar, keine ungewollten SRLG-Kollisionen.
• Label/Encap: keine neuen Drops durch MTU/Encapsulation.

Post-Check L3: Nach der Änderung – Routing stabil, Reachability sauber

Routing-Post-Checks müssen nicht „alles prüfen“, sondern die wichtigsten Stabilitätsindikatoren: Konvergenz, Churn, selektive Reachability, Anycast-Shift. Die beste Praxis ist, einen kleinen Satz repräsentativer Probes (Matrix) zu haben, der jede größere Fault Domain abdeckt.

Post-Check L3 – IGP/BGP Stabilität

• IGP: keine neuen adjacency flaps, keine auffälligen SPF-Spikes.
• BGP: Sessions stabil, Route Churn im Baseline-Bereich, keine Prefix-Limit Events.
• Policy: keine unerwarteten Route Withdraws oder Filtereffekte.

Post-Check L3 – Reachability & Path Validation

• Probe-Matrix: POP↔POP, POP↔Peering, POP↔Service-Edge (DNS/AAA), erfolgreich.
• Destination-Selektivität: Stichproben zu kritischen ASNs/Targets (CDNs, Cloud-Provider, Payment, Messaging).
• Anycast Dienste: keine ungewollten Announcement-Shifts; Latenz bleibt stabil.

Post-Check „Service Lens“: Warum L1–L3 nicht reicht

Auch wenn der Auftrag L1–L3 ist, ist es in der Praxis sinnvoll, nach einem Backbone-Change mindestens einen „Service Lens“-Kurzcheck zu machen, weil Kundenprobleme oft erst dort sichtbar werden. Dieser Check ist bewusst minimal und soll nur bestätigen, dass keine unerwarteten Nutzerwirkungen auftreten.

• DNS: Resolution Time und Timeout Rate stabil.
• Internet KPI: P99-Latenz und Timeout-Rate stabil (aggregiert nach Region).
• Mobile/Voice (falls betroffen): Session Setup/Registration stabil.

Abort- und Rollback-Regeln: Wann Sie sofort stoppen müssen

Ein Change-Window ist nur dann sicher, wenn Abbruchkriterien vorher definiert sind. Wichtig ist, dass die Kriterien messbar sind und nicht von Diskussionen abhängen. Zwei grundlegende Quoten helfen oft: DropRate und ein Routing-Stabilitätsindikator (Churn oder Adjacency Flaps).

DropRate als Guardrail (MathML)

$\mathrm{DropRate}=\frac{\mathrm{dropped\_packets}}{\mathrm{total\_packets}}$

ChurnRate als Guardrail (MathML)

$\mathrm{ChurnRate}=\frac{\mathrm{route\_updates}}{\mathrm{time\_window}}$

• Abort-Beispiele: DropRate steigt > X% über Baseline oder ChurnRate steigt > Y über Baseline für Z Minuten.
• Rollback: immer in dokumentierter Reihenfolge, mit Mini-Post-Check nach jedem Schritt.
• Kommunikation: IC informiert NOC/Stakeholder, sobald Abort/rollback ausgelöst wird.

Dokumentation im Change-Window: Evidence Pack light

Damit Changes auditierbar sind und spätere Analysen (bei Nebenwirkungen) schnell funktionieren, sollten Sie ein minimales Evidence Pack erstellen. Es reicht oft, die wichtigsten Pre/Post-Ansichten zu verlinken oder als Export abzulegen, jeweils mit fixiertem Zeitfenster.

• 00_meta: Change-ID, Scope, Owner, Start/Ende, Rollback Plan
• 10_L1: Optik/BER/FEC, Link Flaps, Errors
• 20_L2: Utilization, Queue Drops, LSP/TE State, MTU Hinweise
• 30_L3: IGP/BGP Stability, Churn, Reachability Matrix
• 40_notes: Entscheidungen, Abweichungen, Follow-ups

Typische Fehler und wie die Checkliste sie verhindert

• Change startet in Degradation: Pre-Check L1/L2 erkennt FEC/Queueing früh.
• Schutzpfad überlastet: Headroom-Check und erwarteter Traffic-Shift verhindern Hot Links.
• Routing instabil nach Change: Churn/Adjacency-Checks decken Nebenwirkungen sofort auf.
• MTU Blackholes: MTU/Encapsulation Pre-Checks verhindern stille Drops.
• Keine Validierung: Post-Checks erzwingen „Done“-Signale statt Bauchgefühl.

Weiterführende Ressourcen

• ISO/IEC 7498-1 (OSI Reference Model)
• IETF Standards (Routing- und Transportreferenzen)
• tc(8) – Traffic Control (Queueing/Drops, relevant für Host-nahe Diagnostik)
• PagerDuty Incident Response (Prozess- und Rollenmuster)
• Google SRE Workbook: Incident Response

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.