Eine belastbare Source of Truth ist in Telco- und Provider-Netzen der Unterschied zwischen „wir betreiben ein Netz“ und „wir reagieren auf Überraschungen“. Je größer eine Topologie wird, desto schneller entsteht Drift: Ports werden umgepatcht, Link-Labels stimmen nicht mehr, VRFs werden in einer Region anders benannt, IP-Pläne werden erweitert, aber nicht konsolidiert, und plötzlich passt das Diagramm nicht mehr zur Realität. In der Praxis sind solche Inkonsistenzen teuer: Incidents dauern länger, weil Teams zuerst herausfinden müssen, was wirklich ist. Changes werden riskanter, weil Abhängigkeiten nicht korrekt erkannt werden. Audit- und Compliance-Anforderungen lassen sich schlechter erfüllen, weil Nachweise fehlen oder widersprüchlich sind. Genau hier setzt das Source-of-Truth-Prinzip an: Topologie- und Asset-Daten werden in einem zentralen System – häufig NetBox oder einer klassischen CMDB – konsistent gehalten, versioniert, mit klaren Verantwortlichkeiten gepflegt und für Automatisierung nutzbar gemacht. Wichtig ist dabei: „Source of Truth“ bedeutet nicht „wir haben ein Tool“, sondern „wir haben einen verbindlichen Datenvertrag“. Welche Attribute gelten als wahr? Welche Systeme dürfen welche Daten schreiben? Wie werden Änderungen durchgesetzt (Change-Gates)? Wie wird Drift gemessen (Validation)? Und wie werden Layer (L1/L2/L3/Services) getrennt, aber über eindeutige IDs verknüpft? Dieser Artikel zeigt, wie Sie Topologie-Daten mit NetBox/CMDB konsistent halten – mit einem praxistauglichen Datenmodell, klaren Ownership-Regeln, Integrationen in Provisioning/Automation, sowie kontrollierten Workflows, die den Betrieb beschleunigen statt ihn zu blockieren.
Warum eine Source of Truth in Telco-Topologien unverzichtbar ist
Provider-Netze sind dynamisch: neue PoPs, neue Interconnects, Upgrades, Service-Expansion, Multi-Vendor-Hardware, DCI-Verbindungen, Remote Sites. In diesem Tempo scheitert „Doku in Wikis“ oder „Excel als Inventar“ fast zwangsläufig. Eine Source of Truth schafft ein konsistentes Inventar und macht Topologie „abfragbar“: für Betrieb, Planung, Kapazität, Security und Automatisierung.
- Incident-Beschleunigung: Schneller klären, welche Links, SRLGs, VRFs oder Peers betroffen sind.
- Change Risk reduzieren: Abhängigkeiten und Failure Domains sind sichtbar; Canary- und Rolling-Upgrades werden planbar.
- Automation ermöglichen: Provisioning, Konfig-Generierung und Compliance-Checks benötigen zuverlässige Daten.
- Auditability: Nachweisbare Änderungen, Asset-Historie, konsistente Namenskonventionen und Ownership.
- Capacity & Forecasting: Verlässliche Link-/Port-/Device-Daten sind Grundlage für Headroom-Modelle.
Leitprinzip: Daten sind ein Produkt mit SLAs
Wenn Topologie-Daten geschäftskritisch sind, brauchen sie Qualitätssicherung: Aktualität, Vollständigkeit, Korrektheit und Verantwortlichkeiten – ähnlich wie ein Service mit SLOs.
NetBox vs. CMDB: Rollen, Stärken und typische Einsatzmuster
NetBox wird häufig als Netzwerk-fokussierte Source of Truth genutzt: Geräte, Interfaces, IPAM, Circuits, VLANs, VRFs, Standorte und Beziehungen. Eine CMDB (z. B. im ITSM-Kontext) ist oft breiter: sie modelliert Configuration Items (CIs), Services, Business-Abhängigkeiten, Ownership, Change-Prozesse und Asset-Lifecycle. In Telco-Umgebungen ist ein bewährtes Muster: NetBox als technische Wahrheit für Netzwerkobjekte, CMDB/ITSM als Wahrheit für Prozesse, Servicebeziehungen und Governance – mit klarer Datenhoheit pro Feld.
- NetBox stark bei: IPAM, Device/Interface/Port-Modelle, Circuit-Management, Standortmodell, Topologiebeziehungen.
- CMDB stark bei: Service-Modelle, Ownership/Teams, Change-/Incident-Verknüpfung, Lifecycle, Compliance-Prozesse.
- Gemeinsamer Erfolgsfaktor: Klare Datenhoheit: Wer ist „System of Record“ für welches Attribut?
- Integration statt Konkurrenz: Doppelte Wahrheit vermeiden, über IDs und Sync-Regeln verknüpfen.
Designregel: Ein Attribut hat genau einen Schreibmeister
Wenn Standortnamen, Device-IDs oder IP-Prefixe sowohl in NetBox als auch in der CMDB „editierbar“ sind, entsteht Drift. Definieren Sie pro Feld: NetBox schreibt, CMDB liest – oder umgekehrt.
Layer-Datenmodell: L1/L2/L3/Services getrennt halten – aber verknüpfen
Eine Source of Truth wird schnell unbrauchbar, wenn Layer vermischt werden. Besser ist ein Multi-Layer-Modell: L1 als Circuits/SRLG/Ports, L2 als VLANs/Bridging-Domänen, L3 als Prefixe/IGP/BGP/VRFs, Services als Produktobjekte und Servicekanten. Verknüpft wird über eindeutige IDs (Circuit-ID, Link-ID, Device-ID, VRF-ID, Service-ID).
- L1-Objekte: Standorte, Racks, Devices, physische Ports, Circuits, Trassen/SRLG, Optiken.
- L2-Objekte: VLAN/QinQ, LAG, Bridging-Domänen, EVPN/VPLS-Instanzen (je nach Modellierung).
- L3-Objekte: Prefixe, IP-Interfaces, VRFs, Routing-Domänen, Peerings (BGP-Sessions).
- Service-Objekte: L2VPN/L3VPN-Produkte, Internet-Access, DDoS-Schutz, CGNAT/BNG-Services, SLOs.
Anti-Pattern: „Alles ist ein Feld in einem Objekt“
Wenn ein Device-Objekt plötzlich Service-SLOs, Peering-Verträge und Trasseninformationen enthält, ist es nur eine Frage der Zeit, bis Daten inkonsistent werden. Trennung schafft Klarheit und Skalierbarkeit.
Namenskonventionen und IDs: Der unsichtbare Klebstoff
Saubere Identifier sind die Grundlage für konsistente Topologie-Daten. Ohne einheitliches Naming können Sie weder automatisieren noch zuverlässig korrelieren. Besonders wichtig ist ein global eindeutiges Schema für Sites/PoPs, Rollen, Devices, Links und Circuits – unabhängig vom Vendor.
- Site-/PoP-ID: Kurz, eindeutig, stabil (z. B. Region-Stadt-PoP-Code).
- Device-ID: Rolle + Standort + Index (z. B. EDGE01, CORE02), konsistent über alle Systeme.
- Link-/Circuit-ID: Provider- oder interne Circuit-IDs, Port-zu-Port referenzierbar.
- VRF-/Service-ID: Einheitliche Namen und ggf. RT/RD-Schemata, die die Topologie widerspiegeln.
Designregel: IDs müssen „lebenslang“ sein
Ein Gerät kann umgebaut werden, Ports können wechseln, Services können migrieren – aber IDs sollten stabil bleiben, sonst verlieren Logs, Tickets und Dashboards ihren Bezug.
Workflows: Wie Datenkonsistenz im Tagesgeschäft entsteht
Der größte Fehler ist, Source of Truth als „Dokuprojekt“ zu behandeln. In der Praxis muss jede Änderung am Netz einen Datenworkflow haben: Planung → Reservierung → Umsetzung → Validierung → Abschluss. NetBox/CMDB wird damit Teil des Change-Prozesses, nicht nur ein Nachtrag.
- Design/Plan: Neue Prefixe, VLANs, Circuits werden im System reserviert und geprüft (Kollisionen vermeiden).
- Build: Provisioning nutzt Daten aus der SoT (Templates/Automation), nicht aus „freien Texten“.
- Deploy: Änderungen werden umgesetzt, idealerweise idempotent (Config-as-Code).
- Validate: Post-Checks: stimmen Ports, IPs, BGP-Neighbor, MTU, QoS, Labels, Peerings?
- Close: Change wird nur geschlossen, wenn SoT aktualisiert und validiert ist.
Change-Gates: „No SoT, no change“
Ein pragmatisches Gate lautet: Keine produktive Änderung ohne aktualisierte SoT-Daten und ohne Validation. Das klingt streng, reduziert aber langfristig OPEX und Incident-Risiko.
Integration: SoT als Motor für Automation und Provisioning
Der größte Nutzen entsteht, wenn SoT-Daten direkt in Automatisierung fließen: Konfig-Generierung, Peerings, VRFs, ACLs, QoS-Profile, Telemetry-Targets. Dafür brauchen Sie klare Datenverträge: welche Felder sind Pflicht, welche optional, welche validiert? Ohne Validierung wird Automation zur Fehlerverstärkung.
- Config-as-Code: Templates pro Rolle (Core, Edge, PE, BNG), Variablen aus SoT.
- IPAM-driven Provisioning: Interfaces bekommen IPs aus reservierten Prefixen, keine „handgemachten“ Adressen.
- Service-Provisioning: VRF- und Policy-Definitionen als Serviceobjekte, die gerendert und ausgerollt werden.
- Telemetry-by-Design: Collector-Targets, Labels (Region/PoP/Rolle) und Limits aus SoT ableiten.
Designregel: Automation liest, Menschen schreiben – mit Regeln
In der Praxis schreiben Menschen die SoT (mit Review/Workflow), Automation konsumiert sie. Direkte automatische Writes sind möglich, aber nur mit klarer Ownership und Konfliktlogik, sonst überschreiben Systeme sich gegenseitig.
Drift Detection: So erkennen Sie Inkonsistenzen früh
Eine SoT bleibt nur verlässlich, wenn Drift sichtbar wird. Drift entsteht durch manuelle Änderungen, Notfallmaßnahmen, Patchfehler, unvollständige Rollbacks oder veraltete Daten. Drift Detection ist deshalb Pflicht: regelmäßige Abgleiche zwischen „Soll“ (SoT) und „Ist“ (Netz).
- Interface/Port Drift: Port-Status, Speed, LAG-Members, Cross-Connects vs. SoT.
- IP Drift: IP-Interfaces, Loopbacks, Subinterfaces vs. IPAM.
- Routing Drift: BGP Neighbors, VRFs, Prefix-Counts, Communities vs. erwartete Policies.
- Service Drift: VRF-Existenz, RT/RD, QoS-Policies, Security-ACLs vs. Blueprint.
- L1 Drift: Circuit-Status, Provider-IDs, SRLG-Zuordnung, Patchfelder.
Ein Drift-Signal als einfache Logik
Wenn der Ist-Zustand vom Soll abweicht und es keine zugehörige Change-ID gibt, ist die Wahrscheinlichkeit hoch, dass es sich um unkontrollierte Drift handelt.
Datenqualität: Pflichtfelder, Validierungen und „Definition of Done“
Eine häufige Ursache für schlechte SoT ist Unklarheit: Welche Felder sind Pflicht? Was ist „vollständig“? Definieren Sie pro Objektklasse eine „Definition of Done“. Für Links sind z. B. beide Enden, Circuit-ID, SRLG und Kapazität Pflicht. Für BGP-Peerings sind ASN, Neighbor-IP, Policy-Typ und Max-Prefix Pflicht. Validierungen sollten automatisiert sein (z. B. keine doppelten Prefixe, keine unbenannten Interfaces, keine VRF ohne Owner).
- Pflichtfelder pro Objekt: Device (Rolle, Standort), Interface (Name, Typ, Speed), Circuit (ID, Endpunkte), Prefix (Scope, Nutzung), VRF (Name, RT/RD).
- Constraint Checks: Keine IP-Kollisionen, keine VLAN-Kollisionen, Namensschema eingehalten.
- Ownership: Team/Owner und Lifecycle-Status (planned/active/decom) als Pflicht, sonst entsteht Datenmüll.
- Audit-Trail: Wer hat was wann geändert, mit Change-ID.
Anti-Pattern: „Wir tragen erstmal grob ein“
Grob wird selten später präzise. Besser ist ein Minimalstandard, der sofort nützlich ist, und dann schrittweise Erweiterung – aber mit klaren Pflichtfeldern und Validierungen.
Operating Model: Rollen, Verantwortlichkeiten und Konfliktlösung
Eine SoT ist ein sozio-technisches System. Ohne Rollenmodell wird es entweder zu streng (und umgangen) oder zu locker (und driftet). Bewährt ist eine Trennung: Netzengineering definiert Blueprints und Standards, Betrieb pflegt Tagesänderungen innerhalb dieser Standards, und ein Plattform-/Tooling-Team betreibt NetBox/CMDB und Integrationen. Konflikte werden über Reviews, Change-Gates und klare Eskalationswege gelöst.
- Network Architecture: Datenmodell, Blueprints, Namenskonventionen, Policy-Verträge.
- Network Operations: Pflege und Umsetzung im Tagesgeschäft, Incident-Updates, Lifecycle-Status.
- Tooling/Platform: NetBox/CMDB Betrieb, Integrationen, Validierungs-Pipelines, Backups.
- Service Owner: Verantwortung für Serviceobjekte (VRFs, SLOs, Kundenbeziehungen) und deren Aktualität.
Designregel: Fehlerkosten transparent machen
Wenn Teams sehen, wie viel Zeit Incidents durch falsche Daten kosten, steigt die Akzeptanz für Change-Gates und Pflichtfelder. Datenqualität ist ein OPEX-Thema.
Typische Stolpersteine und wie man sie vermeidet
- Doppelte Wahrheit: Lösung: pro Attribut genau ein System-of-Record, klare Sync-Regeln.
- Unklare Pflichtfelder: Lösung: Definition of Done pro Objektklasse, automatische Validierungen.
- Drift durch Notfälle: Lösung: Incident-Runbooks mit „Post-Incident SoT Sync“ als Pflichtschritt.
- Zu viel Detail zu früh: Lösung: minimal nützliches Modell starten, aber mit stabilen IDs und Namensschema.
- Automation ohne Guardrails: Lösung: Policy-as-Code, Tests, Canary-Rollouts, Rollback, bevor großflächig deployt wird.
- Fehlende Ownership: Lösung: Owner/Lifecycle als Pflicht; ohne Owner wird nicht in Betrieb genommen.
Praktische Leitlinien: Topologie-Daten mit NetBox/CMDB konsistent halten
- Datenhoheit definieren: Für jedes Attribut festlegen, ob NetBox oder CMDB die Quelle ist; keine Doppelbearbeitung.
- Layer-Modell umsetzen: L1/L2/L3/Services getrennt modellieren, über stabile IDs verknüpfen.
- Namenskonventionen erzwingen: Site-/Device-/Link-/VRF-IDs standardisieren, „lebenslange“ Identifiers verwenden.
- Change-Gates etablieren: Keine produktive Änderung ohne SoT-Update und Validierung; Change-ID als Pflichtfeld.
- Drift Detection automatisieren: Regelmäßige Soll/Ist-Abgleiche für Ports, IPs, BGP/VRFs, Circuits und SRLGs.
- Pflichtfelder und Constraints: Definition of Done pro Objektklasse, automatische Checks gegen Kollisionen und Drift.
- Automation sicher anbinden: Config-as-Code aus SoT, aber mit Tests, Canary, progressive Rollouts und Rollback.
- Observability verknüpfen: Labels (Region/PoP/Rolle) aus SoT nutzen, Dashboards und Alerts daran ausrichten.
- Operating Model klären: Rollen für Architecture, Operations, Tooling und Service Owner; Konfliktlösung und Reviews definieren.
- Kontinuierlich verbessern: Post-Incident Reviews, Datenqualitäts-KPIs und regelmäßige Audits, damit die SoT dauerhaft verlässlich bleibt.
