Eine Topology Review Checkliste ist für Telcos und Provider ein zentrales Werkzeug, um Carrier-Grade Designs zuverlässig zu bewerten, bevor sie gebaut oder verändert werden. In großen Netzen entstehen die teuersten Incidents selten durch „falsche CLI-Syntax“, sondern durch Designlücken: unklare Failure Domains, scheinbare statt echte Redundanz, inkonsistente Routing- und Policy-Modelle, MTU- und QoS-Regressionen oder fehlende Betriebs- und Nachweisbarkeit. Genau hier setzen Experten-Gates an. Ein Gate ist eine prüfbare Bedingung, die ein Design erfüllen muss, bevor der nächste Schritt erlaubt ist – ähnlich wie Stop/Go-Kriterien in einer CI/CD-Pipeline. In Carrier-Grade Umgebungen sollten Topology Reviews deshalb nicht als einmalige Folienrunde stattfinden, sondern als wiederholbarer Prozess: mit klaren Kriterien, objektiven Nachweisen (Evidence), definierten Verantwortlichkeiten und einem „Definition of Done“ pro Layer (L1/L2/L3/Services/Ops). Die Checkliste in diesem Artikel ist so strukturiert, dass sie sowohl Einsteigern Orientierung gibt als auch Profis eine robuste Review-Methodik bietet: vom physischen Design (SRLG, Trassen, Facility-Risiken) über IGP/BGP/SR, Interconnect- und Security-Policies bis hin zu Observability-by-Design, Change- und Rollback-Strategien. Ziel ist, Designs so zu prüfen, dass Redundanz nicht zur Komplexitäts-Explosion wird, sondern zu messbarer Resilienz, planbaren Wartungsfenstern und niedrigeren Betriebskosten.
Wie man die Checkliste nutzt: Review als Pipeline statt als Meeting
Ein Topology Review wird am effektivsten, wenn es als mehrstufiger Prozess verstanden wird. Jede Stufe hat eigene Nachweise und akzeptiert nur Designs, die die Gate-Kriterien erfüllen. Das verhindert, dass man später „nachbessert“, wenn es teuer ist. Praktisch funktioniert das wie ein Review-Workflow: Datenqualität → Architekturfit → Failure-Engineering → Policy- und Security-Engineering → Operability.
- Gate-Charakter: Jedes Item ist als „erfüllt/nicht erfüllt“ formulierbar.
- Evidence: Für kritische Punkte ist ein Nachweis erforderlich (Messung, Test, Simulation, Lab, Intent Validation).
- Scope: Gate gilt immer für eine definierte Domäne (Region/PoP/Ring/DCI/Serviceklasse).
- Ownership: Jedes Gate hat einen Owner (Architecture, Operations, Security, Tooling).
Leitprinzip: Erst „Design korrekt“, dann „Deploy schnell“
Automatisierung beschleunigt Changes. Sie verstärkt aber auch Fehler, wenn das Design unklar ist. Deshalb gehören Gates vor den Rollout, nicht danach.
Gate 1: Problemdefinition und Zielkriterien sind klar
Ein Carrier-Grade Design muss auf konkrete Anforderungen ausgerichtet sein. Ohne klare Zielkriterien wird ein Designreview zur Meinungsrunde. Deshalb beginnt die Checkliste mit der Frage: Was ist das Ziel – und wie wird Erfolg gemessen?
- Serviceziele: Welche Dienste werden getragen (Internet, L3VPN, Mobile Backhaul, FTTH, DCI)?
- SLOs/SLAs: Verfügbarkeit, Latenzbudgets, Jitter, Loss, Recovery-Ziele (z. B. Link/Node-Failover).
- Skalierung: Erwartete Wachstumsmodelle (Ports, Sites, Sessions, Prefixe, VRFs, TE-Policies).
- Constraints: Budget, Zeit, vorhandene Infrastruktur, Vendor-Standards, regulatorische Anforderungen.
Anti-Pattern: „Wir modernisieren“ ohne messbare Ziele
„Modern“ ist kein Requirement. Ein Gate verlangt messbare Ziele (z. B. p99 RTT < X, N-1 Headroom > Y, Change-Failure-Rate < Z).
Gate 2: Datenbasis und Dokumentation sind reviewfähig
Ein Review kann nur so gut sein wie die Daten. Carrier-Grade Reviews sollten deshalb eine Mindestqualität der Dokumentation erzwingen: Multi-Layer, konsistente IDs, und eine Source-of-Truth-Referenz. Ohne das entstehen später Drift, Missverständnisse und operative Lücken.
- Multi-Layer Doku: L1/L2/L3/Services/Management getrennt dokumentiert.
- Stabile IDs: Site-ID, Device-ID, Link/Circuit-ID, VRF/Service-ID konsistent.
- Source of Truth: Klare Aussage, welches System für welche Attribute „schreibend“ ist.
- Abhängigkeitsgraph: Welche Services hängen von welchen Knoten/Links/PoPs ab?
Designregel: „No SoT, no review“
Wenn die Baseline nicht konsistent ist, ist ein Designreview nur eine Hypothese. Das Gate sollte Mindestqualität erzwingen, bevor technische Details diskutiert werden.
Gate 3: L1-Redundanz ist echt (SRLG, Facility, Power, Trasse)
Viele „redundante“ Designs scheitern am physischen Layer. Carrier-Grade bedeutet: Redundanz ist nicht nur logisch, sondern physisch divers. Dieses Gate prüft SRLGs, Trassen, Gebäudeeinführungen und gemeinsame Abhängigkeiten (MMR, Switch-Fabrics, Strom).
- SRLG-Disziplin: Redundante Pfade teilen keine kritischen Risiken (Trasse, Fiber-Bundle, Patch-Panel).
- Dual-Homing Diversität: Uplinks gehen zu unterschiedlichen Aggregations-/Core-Knoten in getrennten Domains.
- Facility-Risiken: PoP-A und PoP-B nicht im gleichen Gebäude- oder Stromrisiko (wo möglich).
- Nachweis: Port-to-Port Dokumentation, Circuit-IDs, Trasseninformationen und Abnahmetests.
Anti-Pattern: „Zwei Links“ ohne SRLG-Analyse
Ein Baggerereignis oder eine Facility-Störung kann beide Links gleichzeitig treffen. Ohne SRLG-Transparenz ist Redundanz eine Illusion.
Gate 4: Failure Domains und Wartungsdomänen sind explizit
Carrier-Grade Designs müssen definieren, welche Ausfälle lokal bleiben sollen und wie Wartung ohne großflächigen Impact funktioniert. Dieses Gate prüft, ob Failure Domains (PoP, Region, Ring, DCI) und Maintenance Domains (Upgrade-Wellen) sauber geschnitten sind.
- Failure Domain Map: PoP/Region/Ring/DCI als klare Domänen mit definierter Blast-Radius-Erwartung.
- Maintenance Domains: Upgrades dürfen nie beide Redundanzseiten gleichzeitig treffen.
- Degraded Mode: Verhalten und SLOs im N-1 Betrieb sind definiert (inkl. QoS-Failover-Profil).
- Nachweis: Rollout-Plan, Wellenlogik, und Failure-Workshops.
Designregel: Planned Failure ist ein eigener Lastfall
Wartung ist planbar – genau deshalb muss sie im Design als „N-1-Modus“ vorgesehen sein, nicht als Ausnahme.
Gate 5: Topologiepattern sind bewusst gewählt (Ring/Mesh/Hub-Spoke)
Dieses Gate prüft, ob die gewählte Topologie zur Anforderung passt. Ringe bieten klare Protection, Mesh bietet bessere Auslastung, Hub-Spoke vereinfacht – aber erzeugt Hub-Kritikalität. Ein Carrier-Grade Review verlangt, dass diese Trade-offs explizit dokumentiert und durch KPIs gestützt werden.
- Begründung: Warum diese Topologie? Welche Alternativen wurden verworfen und warum?
- Skalierungsgrenzen: Ab wann wird ein Ring gesplittet? Ab wann wird Mesh sinnvoll?
- Engpasspunkte: Wo entstehen Congestion-Risiken und wie werden sie adressiert (Headroom/QoS/TE)?
- Interop: Passt die Topologie zu Multi-Vendor und zu den Betriebsprozessen?
Anti-Pattern: Topologie „historisch“ übernehmen
„War schon immer so“ ist keine Begründung. Ein Gate fordert eine klare Designentscheidung mit messbaren Kriterien.
Gate 6: IGP-Design ist stabil und skalierbar
IGP ist die Basis für Underlay und oft auch für SR. Dieses Gate prüft Hierarchie, Flooding-Scopes, Timerprofile, Summarization und Stabilitätsmechaniken (Throttling). Ziel ist, Control-Plane-Churn zu begrenzen und Konvergenz vorhersehbar zu machen.
- Hierarchie: Areas/Levels passend zur Topologie, keine „flache“ Domäne ohne Begründung.
- Summarization: Aggregation und Topologie sind abgestimmt; keine zufälligen Prefixe ohne Hierarchie.
- Timer/Tuning: Konservativ und getestet; keine aggressiven Profile ohne Nachweis.
- Schutz: BFD-Profile und IGP-Protection-Mechaniken konsistent, mit klaren Zielen.
Designregel: IGP ist ein Transportprotokoll, kein Policy-Werkzeug
Wenn IGP-Metriken genutzt werden, um Business-Policy zu erzwingen, entsteht Fragilität. Policy gehört in BGP/TE.
Gate 7: Segment Routing ist konsistent (SRGB, SIDs, Policies, FRR)
Wenn SR genutzt wird, ist Konsistenz der Schlüssel. Dieses Gate prüft SRGB-Plan, SID-Zuweisung, FRR/TI-LFA Coverage und die Governance für SR-Policies (distributed vs. Controller). Besonders wichtig ist der Nachweis: Welche Failure Cases sind geschützt?
- SRGB-Plan: Einheitlich, explizit konfiguriert, dokumentiert.
- SID-Strategie: Node-SIDs/Anycast-SIDs aus klaren Pools; keine unkontrollierten Defaults.
- FRR/TI-LFA: Coverage-Ziele und Messmethodik; Lücken als Engineering-Backlog.
- Policy Governance: Wer darf Policies ändern? Welche Guardrails verhindern Hotspots?
Anti-Pattern: SR aktivieren ohne Coverage-Nachweis
Carrier-Grade verlangt, dass Schutzkonzepte messbar sind. „TI-LFA sollte schon gehen“ ist kein Nachweis.
Gate 8: BGP-Design ist hierarchisch, redundant und leak-resistent
BGP ist im Provider-Netz die wichtigste Policy- und Skalierungsebene. Dieses Gate prüft iBGP-Topologie (RR-Design), Redundanz, Failure Domains, Max-Prefix, Export-Whitelists und No-Transit-Regeln. Ziel ist, Routing-Failures topologisch zu vermeiden.
- RR-Placement: Mindestens zwei RRs pro Client in getrennten Failure Domains.
- Hierarchie: Regionale RRs und klare Domänengrenzen; kein unkontrolliertes Full Mesh.
- Guardrails: Max-Prefix, Default-deny Export, Leak-Prevention, Community Contract.
- Failure Handling: Partition-Szenarien geprüft, Split-Brain-Risiken minimiert.
Designregel: Leaks werden vor dem Deploy gestoppt
Leak-Prevention gehört in Pre-Change-Gates (Intent Validation), nicht nur ins Monitoring. Ein Leak kann global in Minuten eskalieren.
Gate 9: Service-Topologie ist sauber (VRFs, L2/L3VPN, Service Chains)
Carrier-Grade bedeutet: Services sind topologisch sauber abgebildet und voneinander isoliert. Dieses Gate prüft VRF-Modelle, Route Targets, EVPN/L2VPN-Designs und Service Chains (CGNAT, Firewalls, DPI), inklusive Symmetrieanforderungen.
- VRF-Isolation: Keine unerlaubten Route Leaks, Leaking nur explizit und dokumentiert.
- Service-Blueprints: Standardmodelle für E-Line/E-LAN/L3VPN, inklusive QoS und Monitoring.
- Service Chains: Pfadsymmetrie und Failure Handling für stateful Funktionen; klarer Steering-Mechanismus.
- Anycast: Health-Gates, Withdraw-Strategien, Region-Failover-Logik.
Anti-Pattern: Service-Design ohne Pfadmodell
Wenn Sie nicht wissen, wie Traffic im Normal- und Failoverfall fließt, können Sie weder QoS noch Sicherheit noch Capacity sauber planen.
Gate 10: QoS-Design ist end-to-end und failoverfest
QoS ist im Carrier-Netz kein optionales Feature, sondern ein Vertrag. Dieses Gate prüft Klassenmodell, Marking/Trust Boundaries, Queueing an Engpässen, Policing und das Verhalten im N-1 Betrieb. Besonders kritisch: QoS muss auch im Schutzpfad funktionieren.
- Klassenmodell: Wenige Klassen, konsistente DSCP-Regeln, klare Produktprofile.
- Trust Boundaries: Wo wird Marking akzeptiert, wo erzwungen, wo verworfen?
- Engpasspunkte: DCI, Interconnect, Metro-Hubs, Access-Aggregation – dort Queueing und Budgets.
- Degraded Mode: Failover-QoS-Profil definiert; Bulk wird begrenzt, kritische Klassen geschützt.
Designregel: QoS wird an Engpässen implementiert, nicht „irgendwo“
Wenn Drops in der Aggregation passieren, hilft QoS im Core nicht. Die Checkliste verlangt eine Engpasskarte und passende Profile.
Gate 11: MTU ist end-to-end geplant (Overlays, Labels, Blackhole Prevention)
MTU-Probleme sind klassische „selektive“ Fehler: kleine Pakete funktionieren, große nicht. Dieses Gate prüft Mindest-MTU pro Linkklasse, Overhead (MPLS/SR/EVPN/QinQ), PMTUD/ICMP-Handling und MSS-Strategien. Es fordert explizite Tests für Normal- und Failoverpfade.
- Mindest-MTU: Pro Domäne und Linkklasse definiert, dokumentiert, automatisiert prüfbar.
- Overhead: Label-Stack und Overlay-Header einkalkuliert.
- Blackhole Prevention: PMTUD-freundliche Policies, ICMP nicht blind blockieren.
- Tests: Größen- und Pfadtests, inklusive Mitigation-/Scrubbing- oder DCI-Failoverpfaden.
Anti-Pattern: MTU nur im Normalpfad validieren
Viele MTU-Incidents treten erst bei Umlenkung (Failover, DDoS-Scrubbing) auf. Das Gate verlangt Failover-Tests.
Gate 12: Control-Plane Protection und Security Domains sind integriert
Carrier-Grade Designs brauchen Schutz gegen Control-Plane-Überlast und klare Security Domains. Dieses Gate prüft CoPP, Management-Netze (OOB/In-Band), Jump-Zones, ACLs, RTBH/FlowSpec Governance und Segmentierung nach Services/Kunden/Betriebsrollen.
- CoPP Profile: Rollenbasiert, getestet, mit Monitoring der Drops/Matches.
- Management Topologie: OOB/In-Band klar getrennt, Jump-Zones, Least Privilege Zugänge.
- DDoS Mechaniken: Autorisierte Quellen, Scope/Expiry, Containment; keine globalen „Wild West“-Regeln.
- Segmentierung: VRFs/Security Zones nach Kunden, Services und Betriebsrollen; klare Allowed Flows.
Designregel: Security ist ein Gate, kein späterer Patch
Wenn Security erst nach dem Bau kommt, wird sie teuer und inkonsistent. Carrier-Grade Reviews verlangen Security-by-Design.
Gate 13: Observability-by-Design ist umgesetzt (Telemetry, Flows, SLO-Messung)
Ohne Observability wird Betrieb zum Ratespiel. Dieses Gate prüft Telemetry-Pfade, Sampling-Strategien, Datenmodelle, Flow-Visibility (NetFlow/IPFIX) und SLO-Messung (Availability, Latency). Außerdem verlangt es High-Signal Alarmierung: wenige, aussagekräftige Alerts statt Noise.
- Pflichtmetriken: Loss/RTT, Queue-Drops, Portauslastung, CPU/Memory, IGP/BGP Health, FRR-Events.
- Flow-Visibility: Platzierung und Sampling, um Hotspots, Imbalance und DDoS-Events analysieren zu können.
- SLO-Messung: Topologisch korrelierte Messpunkte (Region/PoP/Rolle/Linkklasse) mit Dashboards.
- Alerting: Korrelation (z. B. Link down + FRR + Drops), Runbook-Verweise, klare Severity-Regeln.
Anti-Pattern: Monitoring nur als Geräte-NMS
Carrier-Grade Observability ist service- und pfadorientiert. Geräte-Status allein reicht nicht, um Degradations zu erkennen.
Gate 14: Change- und Rollback-Strategie ist topologisch sicher
Ein gutes Design ist wertlos, wenn es nicht sicher geändert werden kann. Dieses Gate prüft Canary-Strategie, progressive Rollouts, Stop/Go-Gates und Rollback-Prozeduren. Es verlangt außerdem, dass kritische Changes vorab validiert werden (Intent Validation, Lab-Reproduktion).
- Canary Domains: Repräsentative, begrenzte Scopes für erste Rollouts.
- Wellenlogik: Rollout entlang von Maintenance Domains, nie beide Redundanzseiten gleichzeitig.
- Stop/Go Gates: SLOs, Drops, Prefix-Counts, Churn, Control-Plane Health entscheiden objektiv.
- Rollback: Reversibel, getestet, inklusive Traffic-Steering zurück und Wiederherstellen von Schutzprofilen.
Designregel: Rollback ist ein Designartefakt
Rollback darf nicht erst im Incident erfunden werden. Carrier-Grade Reviews verlangen Rollback-Mechanik als Teil des Designs.
Gate 15: Evidence-by-Design ist vorhanden (Tests, Workshops, Nachweise)
Dieses Gate ist der Abschluss: Es prüft, ob das Design nicht nur „plausibel“ ist, sondern nachweisbar. Evidence kann aus Lab-Reproduktion (Containerlab/EVE-NG), Simulationen, Intent Validation, Failure Scenario Workshops und Pilot-/Canary-Ergebnissen kommen.
- Failure Workshops: Link-, Node-, Region-Ausfälle; Expected vs. Observed dokumentiert.
- Intent Validation: Leaks, Max-Prefix, MTU, QoS, VRF-Isolation, CoPP als Pre-Change-Checks.
- Lab-Reproduktion: Kritische Pfade und Protokolle im Lab nachgebildet, inklusive Failover.
- Evidence Archive: Reports, Diffs, Metriken, Entscheidungen und Ausnahmegenehmigungen versioniert.
Ein praktisches Gate-Kriterium als Formel
Diese Logik ist bewusst einfach: ohne klare Anforderungen, definierte Failure Domains, verifizierte Guardrails und Nachweise gibt es kein „Go“.
Praktische Leitlinien: Die Checkliste als Standard im Carrier-Grade Prozess verankern
- Checkliste in Templates gießen: Für Core, Metro, Internet Edge, FTTH, Mobile Backhaul je ein Profil, aber gleiche Gate-Struktur.
- Gates automatisieren, wo möglich: Datenqualität, Policy-Guardrails, MTU/QoS-Checks und Leak-Prevention als Intent Validation.
- Ownership klären: Architektur verantwortet Topologie/Protokolle, Operations verantwortet Wartung/Runbooks, Security verantwortet Domains/CoPP.
- Review nach Domänen schneiden: Region/PoP/Ring/DCI/Serviceklasse separat bewerten, um Klarheit zu behalten.
- Ausnahmen kontrollieren: Exception Workflow mit Ablaufdatum, damit Sonderfälle nicht dauerhaft die Standardarchitektur untergraben.
- Erfolg messen: Change-Failure-Rate, MTTR, Drift-Events, SLO-Compliance und Coverage-KPIs als kontinuierliche Feedbackschleife.
- Nach Incidents nachschärfen: Jede Störung ist Input: neue Gate-Regel, neues Testkriterium oder klarere Domänengrenze.
