Site icon bintorosoft.com

Topology Review Checkliste: Experten-Gates für Carrier-Grade Designs

Red Snapper

Portrait of a system engineer explaining complex system integration to a team, using a tablet to display network diagrams, professional demeanor

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.

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?

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.

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

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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

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.

Ein praktisches Gate-Kriterium als Formel

Pass= (RequirementsClear) &wedge; (FailureDomainsDefined) &wedge; (GuardrailsVerified) &wedge; (EvidenceProvided)

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

Exit mobile version