Multi-Layer Topology Docs sind in Telco- und Provider-Netzen ein unterschätzter Stabilitätsfaktor. Viele Netzprobleme entstehen nicht, weil Technik „nicht funktioniert“, sondern weil Menschen im Incident oder im Change nicht schnell genug verstehen, wie das Netz tatsächlich aufgebaut ist: Welche Faser geht wohin? Welche L2-Domäne hängt an welchem Ring? Welche L3-Aggregation läuft über welche Hubs? Und welche Services (L2VPN/L3VPN, Internet, Mobile Backhaul, DDoS, CGNAT, BNG/BRAS) nutzen welche Pfade und Policies? Wenn all das in einem einzigen „Monsterdiagramm“ vermischt wird, ist es zwar beeindruckend, aber operativ wenig hilfreich. Der bessere Ansatz ist: Topologie nach Ebenen getrennt dokumentieren – L1 (physisch), L2 (Switching/Bridging), L3 (Routing/IGP/BGP) und Services (VPNs, Internet Edge, Security Chains, Subscriber-Plattformen). Jede Ebene beantwortet andere Fragen, hat andere Change-Risiken und andere Failure Domains. In der Praxis reduziert eine saubere Multi-Layer-Dokumentation Change Risk, beschleunigt Troubleshooting, verbessert Auditability und macht Designs wiederverwendbar: Sie können Blueprints bauen, Maintenance Domains definieren und Failure Scenario Workshops deutlich effizienter durchführen. Dieser Artikel zeigt, wie Sie L1/L2/L3/Services getrennt dokumentieren, welche Inhalte pro Layer zwingend sind, wie man Ebenen verknüpft, ohne sie zu vermischen, und wie Sie Dokumentation so strukturieren, dass sie im Betrieb wirklich genutzt wird – nicht nur im Architektur-Review.
Warum „ein Diagramm für alles“ in Provider-Netzen scheitert
In komplexen Netzen ist die Informationsdichte zu hoch, um alles in einer Darstellung sinnvoll abzubilden. Ein All-in-One-Diagramm wird entweder unlesbar oder so abstrakt, dass es keine Entscheidungen unterstützt. Zudem sind die Ebenen unterschiedlich stabil: L1 ändert sich langsam (Faser, Trasse, Patchfelder), L3 kann sich durch Policies und TE deutlich schneller ändern, und Services ändern sich oft am häufigsten. Wenn Sie diese Ebenen nicht trennen, wird Dokumentation schnell veraltet oder widersprüchlich.
- Unklare Failure Domains: Ein L3-Problem wirkt wie ein L1-Problem, weil Abhängigkeiten nicht sichtbar sind.
- Change-Kollisionen: Wartung an L1 wirkt plötzlich auf Services, weil Servicepfade nicht getrennt dokumentiert sind.
- Schlechte Suchbarkeit: Operative Fragen („Welche Links teilen SRLG?“) gehen in Mischdiagrammen unter.
- Audit- und Compliance-Lücken: Ohne klare Layer-Logik ist Nachweisbarkeit (Evidence) schwer.
Leitprinzip: Ein Layer = eine Fragestellung
Gute Dokumentation beantwortet konkrete Fragen schnell. Deshalb wird jede Ebene separat dokumentiert und über eindeutige Referenzen verknüpft, nicht über visuelle Vermischung.
Das Zielbild: Vier Layer, vier Artefakt-Typen
Multi-Layer Topology Docs funktionieren am besten, wenn Sie pro Layer konsistente Artefakte definieren: Diagramme, Tabellen/Inventare und klare Namenskonventionen. Der Layer bestimmt dabei, welche Wahrheit gilt und welche Identifier als „Primary Key“ dienen.
- L1 (Physical): Standorte, Trassen, Fasern, Wellenlängen, Patchfelder, Port-zu-Port-Verkabelung, SRLG.
- L2 (Link/Bridging): VLAN/QinQ, Link Aggregation, STP (falls relevant), EVPN/VPLS Bridging-Domänen, Rings.
- L3 (Routing): IP-Plan, IGP-Topologie, BGP (iBGP/eBGP, RR), Summaries, TE/Policies, Anycast.
- Services: Produkt-/Servicepfade, VRFs, L2VPN/L3VPN, Internet Edge, DDoS/Scrubbing, CGNAT/BNG, SLOs.
Designregel: Jedes Objekt hat genau einen „Home Layer“
Ein Glasfaserpaar gehört zu L1, auch wenn es einen L3-Link trägt. Eine VRF gehört zu Services, auch wenn sie über L3 transportiert wird. So vermeiden Sie Doppelwahrheiten.
L1-Dokumentation: Physical Topology als Grundlage für echte Failure Domains
L1 ist häufig der am stärksten unterschätzte Layer. Gerade in Telco-Topologien sind viele „überraschende“ Ausfälle eigentlich gemeinsame Risiken (Shared Risk Link Groups): zwei angeblich redundante Links liegen in derselben Trasse, nutzen dasselbe Patchpanel, oder laufen durch denselben POP. Eine gute L1-Doku macht diese Risiken sichtbar – und ermöglicht erst sinnvolle Resilienz- und Wartungsplanung.
- Standortmodell: PoP/CO/DC, Rack/Row, Raum, Facility-Abhängigkeiten.
- Trassen & SRLG: Welche Links teilen physische Risiken (Trasse, Gebäude, Stromversorgung, MMR)?
- Port-zu-Port: Patchpanel-Port, Gerät-Port, Optiktyp, Speed, Wavelength, Faser-ID.
- Transport-Details: DWDM, ROADM, Schutzschaltungen (falls relevant), OTN/Layer-1-Services.
- Wartungsdomänen: Welche L1-Segmente können isoliert gewartet werden, ohne L3/Services zu gefährden?
Anti-Pattern: „Redundant“ ohne SRLG-Nachweis
Wenn L1-Redundanz nicht mit SRLGs belegt ist, ist sie im Ernstfall oft nur scheinbar. L1-Doku ist der Beweis, nicht die Behauptung.
L2-Dokumentation: Switching-, Ring- und Bridging-Domänen sauber trennen
L2 ist der Layer, in dem kleine Designfehler große Blast Radien erzeugen können: Loops, Broadcast-Stürme, MAC-Table-Churn oder unerwartete Flooding-Pfade. Gleichzeitig ist L2 in Telco-Netzen häufig „servicegetragen“: QinQ im Access, VPLS/EVPN für L2VPN, Ring-Topologien in Metro/Access. Eine gute L2-Doku zeigt nicht nur VLANs, sondern L2-Domänen als Failure Domains.
- Domänengrenzen: Welche Geräte/Links gehören zu einer Bridging-Domäne? Wo ist die klare L2/L3-Grenze?
- VLAN/QinQ Plan: VLAN-IDs, S-VLAN/C-VLAN, Tagging, MTU-Overhead, erlaubte VLAN-Sets pro Trunk.
- LAG/MLAG: Bundles, Member-Ports, Hashing-Profile, Failoververhalten.
- Ring-Mechanik: ERPS/Protected Rings (falls verwendet), Schutzrollen, Blocked Links, Konvergenzlogik.
- EVPN/VPLS Services: EVI/VSI, DF-Handling, Multihoming, Flooding-Policies.
Designregel: L2-Domäne ist eine Failure Domain
Dokumentieren Sie L2 nicht als „VLAN-Liste“, sondern als Domänenkarte: Welche Störung kann welche Geräte gleichzeitig beeinflussen? Das ist entscheidend für OT/Access und für L2VPN-Services.
L3-Dokumentation: Routing-Topologie, Adressierung und Policies als Vertrag
L3-Dokumentation ist in Provider-Netzen oft am bekanntesten, aber auch am schnellsten veraltet, wenn sie nicht strukturiert ist. Entscheidend ist, L3 nicht nur als Linknetz zu zeichnen, sondern als Vertrag: Adressierung, IGP-Domänen, Summaries, BGP-Hierarchien, TE-Mechanismen und Failoverpfade. Dazu gehört auch die Trennung zwischen Underlay und Overlay: Was ist Transport, was ist Service-Overlay (EVPN, SR Policies, VPNs)?
- IP-Plan & Aggregation: Prefix-Design passend zur Topologie (Region/PoP/Site), Summarization-Grenzen.
- IGP-Design: OSPF/IS-IS Areas/Levels, Metrikmodell, BFD-Profile, Flooding-Scopes.
- BGP-Design: iBGP, RR-Topologie, eBGP-Edges, Communities, Max-Prefix und Leak-Guardrails.
- ECMP/FRR: Welche Links sind ECMP-fähig? Welche FRR/TI-LFA Coverage wird erwartet?
- Anycast/TE: Anycast-Prefixe, SR-Policies, Steering-Regeln, Latenzbudgets für Multi-Region.
Ein hilfreiches Muster: „Expected Path“ pro Failure Case
Ergänzen Sie L3-Diagramme um erwartete Pfadwechsel: „Link down“, „Node down“, „Region down“. So wird L3-Doku zum Werkzeug für Failure Scenario Workshops und Rolling Upgrades.
Service-Dokumentation: VRFs, Produktpfade und SLOs als eigene Ebene
Services sind die Ebene, die Kunden erleben – und deshalb muss sie getrennt dokumentiert werden. Service-Dokumentation beschreibt nicht nur „wir haben L3VPN“, sondern: Welche VRFs existieren, wie werden sie provisioniert, wo liegen Servicekanten (PE/BNG/CGNAT), welche Security Domains gelten, welche QoS-Klassen sind zugesichert, und wie sieht der Datenpfad topologisch aus (Ingress/Processing/Egress)?
- Servicekatalog: Internet, L3VPN, L2VPN (E-Line/E-LAN), Mobile Backhaul, DDoS, Managed Firewall, Wholesale.
- Servicekanten: PE/CE, BNG/BRAS, CGNAT, Firewall/Scrubbing, DNS/Anycast – pro Service die relevanten Knoten.
- VRF/Segmentation: Mandantentrennung (Wholesale/Retail/Enterprise), Route Leaking Regeln, RT/RD-Plan.
- Policies: QoS, Traffic Steering, Security Rules, Logging/Telemetry, SLA/SLO-Definitionen.
- Servicepfade: Normalpfad und Failoverpfad, inklusive abhängiger Systeme (AAA, PKI, Controller).
Designregel: Services verweisen auf L3, aber ersetzen es nicht
Service-Doku beschreibt „was“ und „wo“, L3 beschreibt „wie geroutet“. Verlinken Sie über eindeutige IDs (VRF-Name, RT/RD, PE-Rolle, Region), statt die L3-Wahrheit in Service-Diagrammen zu duplizieren.
Verknüpfung der Ebenen: IDs, Namenskonventionen und „Drill-down“ statt Mischdiagramm
Die Kunst bei Multi-Layer-Dokumentation ist die Verknüpfung. Sie wollen Drill-down ermöglichen: von Service → L3 Pfad → L2 Domäne → L1 Trasse. Das gelingt nur mit konsistenten Identifiers und Namenskonventionen. Ohne diese werden Layer-Dokumente zu isolierten Inseln.
- Global eindeutige Objekt-IDs: Link-ID, Circuit-ID, Device-ID, Site-ID, VRF-ID – pro Layer klar.
- Namensschema: Region-PoP-Rolle-Nummer (z. B. „DE-BER-EDGE01“), konsistent über alle Tools.
- Cross-References: L3-Link verweist auf L1-Circuit-ID, Services verweisen auf VRF-ID und PE-Rolle.
- Drill-down Navigation: Von Übersichtsdiagrammen zu Details (PoP → Rack → Port), nicht alles auf einmal.
Anti-Pattern: Kopieren statt Referenzieren
Wenn Sie dieselbe Information in mehreren Layern neu zeichnen, entsteht Drift. Besser ist eine Quelle der Wahrheit pro Layer und klare Referenzen zwischen Layern.
Dokumentationsqualität: Aktualität, Ownership und „Docs-as-Code“
In Telco-Umgebungen scheitert Dokumentation selten am fehlenden Willen, sondern an fehlender Pflege. Multi-Layer-Dokumentation bleibt nur aktuell, wenn Ownership klar ist (wer pflegt L1, wer L3, wer Services) und wenn Änderungen automatisch in Dokumentationsartefakte einfließen. Deshalb ist „Docs-as-Code“ bzw. „Source-of-Truth“-Denken entscheidend: Inventar und Konfiguration sind die Quelle, Doku wird daraus abgeleitet oder zumindest validiert.
- Ownership pro Layer: Transport/L1, Netzwerkbetrieb/L3, Service Engineering/Services – klare Verantwortlichkeiten.
- Change-Gates: Kein Change ohne Update/Validation der betroffenen Layer-Doku.
- Automatisierte Checks: Link- und IP-Inventory gegen Config prüfen, Drift erkennen (z. B. fehlende Links, falsche Labels).
- Versionierung: Doku und Blueprints versioniert, mit Change-ID und Rollback-Möglichkeit.
Designregel: Doku ist ein Produkt, kein Nebenprodukt
Behandeln Sie Topologie-Dokumentation wie ein Service: mit SLAs (Aktualität), Monitoring (Drift), und Release-Prozess (Change Reviews).
Multi-Layer Docs im Incident: Schneller zur richtigen Hypothese
Im Incident zählt Zeit. Multi-Layer-Dokumentation unterstützt eine strukturierte Hypothese: Ist es L1 (Trasse/SRLG)? L2 (Loop/Bridging-Domäne)? L3 (Routing/Policy/TE)? Oder Service-spezifisch (VRF/BNG/CGNAT)? Wenn jede Ebene eine klare Karte und ein Inventar hat, wird Troubleshooting reproduzierbar und weniger personengebunden.
- L1-Check: Gibt es gemeinsame SRLGs? Gibt es Wartung? Gibt es physische Alarme auf derselben Trasse?
- L2-Check: MAC-Churn, Ring-Protection, LAG-Member-Status, VLAN-Fehlkonfig.
- L3-Check: IGP/BGP Health, Prefix-Counts, FRR-Aktivierungen, unerwartete Pfadänderungen.
- Service-Check: VRF-Policy, QoS/SLA, Service Edge Health, Session-Churn (BNG/CGNAT).
Dokumentation + Observability als Paar
Dokumentation sagt „wie es sein sollte“, Observability sagt „wie es ist“. Erst zusammen entsteht schnelle Diagnose. Deshalb sollten Layer-Dokumente auf die passenden Dashboards verweisen (Label-Konzept).
Multi-Layer Docs für Change, Upgrades und Failure Workshops
Rolling Upgrades, Canary-Changes und Failure Scenario Workshops profitieren massiv von Layer-Trennung. L1 zeigt, welche Wartung physisch riskant ist. L3 zeigt erwartete Pfadwechsel und N-1 Headroom. Services zeigen, welche Kunden und SLOs betroffen sind. So wird Change Risk messbar und planbar.
- Upgrade-Planung: Maintenance Domains aus L1/L2 ableiten, Upgrade-Sequenzen aus L3/Services.
- Go/No-Go Gates: SLOs und Headroom (Services/L3) plus SRLG-Risiken (L1) vor Wartung prüfen.
- Canary Links: Canary-Auswahl über Layer-Infos: repräsentative L1/L2/L3/Servicepfade.
- Expected vs. Observed: Workshop-Ergebnisse in Layer-Dokumente zurückspielen (z. B. neue Failure Domain Erkenntnisse).
Anti-Pattern: Workshops ohne Layer-Doku
Ohne Layer-Dokumente werden Workshops zu Diskussionen ohne Beweis. Mit Layer-Doku werden sie zu Engineering: Pfade, Domains, KPIs, Maßnahmen.
Typische Fallstricke und wie man sie vermeidet
- L1 ignoriert: Lösung: SRLG und Port-to-Port als Pflicht; „redundant“ nur mit Nachweis.
- L2 nur als VLAN-Liste: Lösung: L2-Domänen und Rings als Failure Domains dokumentieren.
- L3-Diagramme ohne Policies: Lösung: Communities/LocalPref/TE als „Vertrag“ dokumentieren, nicht nur Links.
- Services ohne Pfadmodell: Lösung: Normal- und Failoverpfade pro Service, inklusive Servicekanten und Abhängigkeiten.
- Drift durch Kopien: Lösung: eine Quelle der Wahrheit pro Layer, Cross-References statt Duplikate.
- Keine Ownership: Lösung: Verantwortlichkeiten pro Layer, Change-Gates und automatisierte Drift-Checks.
Praktische Leitlinien: L1/L2/L3/Services getrennt dokumentieren
- Layer klar definieren: L1 = physisch/SRLG, L2 = Bridging-Domänen, L3 = Routing/Policies, Services = Produktpfade/VRFs/SLOs.
- Pro Layer eine Quelle der Wahrheit: Inventar/Config/SoT pro Ebene; Diagramme daraus ableiten oder validieren.
- Objekt-IDs standardisieren: Circuit-ID, Link-ID, Device-ID, VRF-ID als Primary Keys; konsistentes Namensschema.
- Drill-down statt Mischdiagramm: Übersichten mit klaren Verweisen auf Detailansichten, keine „alles auf einmal“-Grafiken.
- Failure Domains dokumentieren: SRLG (L1), L2-Domänen (L2), Routing-/RR-Domänen (L3), Servicekanten (Services).
- Expected Paths ergänzen: Pro Layer relevante Failoverpfade und Wartungswirkungen (besonders L3/Services) dokumentieren.
- Dokumentation operationalisieren: Change-Gates, Canary-Rollouts, Rollback-Prozeduren und Workshop-Feedback in Docs integrieren.
- Observability verknüpfen: Layer-Labels in Telemetry nutzen und Dashboards so strukturieren, dass sie zur Layer-Doku passen.
- Regelmäßig prüfen: Drift-Checks, Quartalsreviews, und Updates nach größeren Topologie-/Policy-Changes.
