Network Automation wird in Telco- und Provider-Netzen erst dann wirklich wirksam, wenn Topologie als Input verstanden wird – nicht als hübsches Diagramm, sondern als strukturierter Datenbestand, der Provisioning, Policies, Guardrails und Observability antreibt. Viele Automatisierungsinitiativen scheitern nicht an Tools wie Ansible, Terraform oder Git, sondern an der Frage: Woher kommt die Wahrheit? Wenn Geräte, Links, VRFs, Adresspläne und Servicekanten nicht konsistent modelliert sind, produziert Automation zwar Konfigurationen, aber sie produziert auch Drift, Sicherheitslücken und Change-Risiko. Die Alternative ist ein topologiegetriebenes Modell: Eine Source of Truth (z. B. NetBox/CMDB) beschreibt L1/L2/L3/Services, Rollen und Failure Domains. Aus diesen Daten werden Konfigurationen generiert, Policies abgeleitet, Telemetry-Labels gesetzt und Change-Workflows mit Validierung verknüpft. So wird Automation nicht „CLI-Scripting“, sondern Industrial Engineering: reproduzierbar, auditierbar, und skalierbar über Regionen, Vendoren und Serviceklassen. In Telco-Topologien ist dieser Ansatz besonders wertvoll, weil die Komplexität nicht linear wächst: Jede neue Region und jeder neue Service erhöht die Zahl möglicher Abhängigkeiten und Failure Cases. Dieser Artikel zeigt, wie Sie Topologie-Daten als Input für Provisioning und Policies nutzen: vom Datenmodell über Blueprints und Templates bis zu Guardrails, Canary-Rollouts, Drift-Detection und Evidence-by-Design – damit Automatisierung Stabilität erhöht statt sie zu gefährden.
Warum Topologie der Schlüssel für erfolgreiche Netzwerkautomatisierung ist
Netzwerkautomatisierung ohne Topologie ist wie Bauplanung ohne Statik: Sie können Dinge schnell „hinsetzen“, aber Sie wissen nicht, wie sie unter Last, Ausfall oder Wachstum reagieren. Topologie liefert den Kontext, den reine Gerätekonfiguration nicht enthält: Rollen (Core/Edge/PE/BNG), Linkklassen (DCI, IXP, Transit), Failure Domains (PoP, Region, SRLG), Adressaggregation und Servicekanten. Genau daraus ergeben sich sichere Policies und robuste Provisioningregeln.
- Kontext statt Einzelgerät: Automation weiß, welche Rolle ein Gerät hat und welche Regeln dafür gelten.
- Skalierung über Blueprints: Neue PoPs/Regionen werden instanziiert, nicht „neu erfunden“.
- Guardrails werden möglich: Max-Prefix, CoPP-Profile, QoS-Modelle, Exportfilter – abhängig von Rolle und Linkklasse.
- Drift wird messbar: Soll-Zustand (Topologie) vs. Ist-Zustand (Netz) kann automatisiert verglichen werden.
- Auditierbarkeit: Änderungen sind nachvollziehbar, weil die Datenquelle und die Renderlogik versioniert sind.
Leitprinzip: Automatisierung beginnt mit einem Datenvertrag
Bevor Sie Konfigurationen generieren, müssen Sie festlegen, welche Topologieattribute verpflichtend sind, wer sie pflegt und wie sie validiert werden. Ohne Datenvertrag ist Automatisierung Zufall.
Der Architektur-Baukasten: Source of Truth, Git, Render Engine, Deploy und Validation
Topologiegetriebene Automation besteht aus wiederkehrenden Bausteinen. Die konkrete Toolwahl ist zweitrangig; wichtig ist die Struktur: SoT liefert Daten, Git hält Blueprints und Templates, eine Render Engine erzeugt gerätespezifische Konfigurationen, Deploy rollt aus, und Validation beweist den Erfolg. Diese Pipeline ist der Kern von E-E-A-T im technischen Sinn: sie macht Engineering-Qualität nachweisbar.
- Source of Truth: NetBox/CMDB für Devices, Interfaces, IPAM, VRFs, Circuits, Sites, Rollen, Tags.
- Blueprints: Standardisierte Muster pro Rolle und Domäne (Core, Edge, DC Fabric, Remote Sites).
- Templates/Render: Jinja/Go-Templates oder deklarative Modelle; Input = Topologieobjekte + Policies.
- Deploy: Automatisiertes Ausrollen (API/NETCONF/gNMI/CLI-Adapter), idealerweise idempotent.
- Validation: Pre-Checks und Post-Checks, die Konvergenz, Policies, MTU, QoS und SLO-Impact prüfen.
Designregel: Validation ist kein Add-on, sondern Teil des Provisionings
In Telco-Netzen ist „Config pushed“ kein Erfolgskriterium. Erfolg ist: Routing stabil, Policies korrekt, SLOs grün, Guardrails aktiv. Das muss automatisiert geprüft werden.
Topologie-Datenmodell: Welche Informationen Automation wirklich braucht
Viele SoT-Modelle sind entweder zu dünn (nur IPAM) oder zu breit (alles in einem Objekt). Für Automation braucht es ein praktisches, layergetrenntes Modell: L1/L2/L3/Services, verknüpft über stabile IDs. Zusätzlich braucht es „Intent“-Attribute: Rolle, Linkklasse, Sicherheitszone, Mandant, Region, Wartungsdomäne. Diese Attribute steuern Policies und Templates.
- Stabile Identitäten: Site-ID, Device-ID, Interface-ID, Circuit-ID, VRF-ID, Service-ID.
- Rollen & Tags: Core/Edge/PE/BNG, IXP/Transit/PNI, DCI, Access, OT/Edge-Site.
- L3/IPAM: Loopbacks, Linknets, Aggregationsprefixe, Anycast-Prefixe, VRF-Prefixe.
- Policy-Inputs: Peer-Typ (Customer/Peer/Provider), QoS-Klasse, CoPP-Profil, Export/Import-Policy.
- Failure Domains: Region/PoP, SRLG, Maintenance Domain, Redundanzpaare.
Anti-Pattern: „Wir automatisieren erst mal nur Geräte“
Geräteautomatisierung ohne Rollen- und Linkklassenmodell führt schnell zu Sonderfällen. Sonderfälle sind der Feind von Skalierung. Besser: erst das Rollenmodell, dann Templates.
Provisioning-Blueprints: Von der Topologie zur Konfiguration
Ein Blueprint ist ein wiederverwendbares Designmuster: Welche Protokolle laufen, welche Interfaces werden wie benannt, welche IPs kommen aus welchem Pool, welche Policies gelten. Blueprints reduzieren Komplexität, weil sie aus vielen Einzelentscheidungen eine standardisierte Instanz machen. Die Instanzierung wird durch Topologiedaten gesteuert: Standort, Rolle, Peers, Kapazität, SRLG.
- Core Blueprint: IGP (OSPF/IS-IS), BFD-Profile, MPLS/SR, FRR/TI-LFA, CoPP-Core.
- Interconnect Blueprint: eBGP, Communities, Max-Prefix, RTBH/FlowSpec-Mechaniken, QoS/Policing an Edge.
- PE/Services Blueprint: VRFs, RT/RD, Route-Leaking Regeln, Service QoS, CE-Topologien (Static/BGP/OSPF).
- Remote Site Blueprint: Dual-WAN, Failover-QoS-Profil, DMZ/Jump-Zone, Telemetry-Limits.
- DC Fabric Blueprint: EVPN/VXLAN, Multihoming-Modell, MTU, Anycast Gateways, Telemetry-Labels.
Designregel: Blueprints definieren auch „verbotene“ Features
Interoperabilität und Stabilität steigen, wenn Sie nicht nur festlegen, was genutzt wird, sondern auch, was nicht genutzt werden darf (z. B. bestimmte BGP-Optionen, exotische Timer, nicht getestete EVPN-Flags).
Policies aus Topologie ableiten: Peer-Typen, Zonen und Guardrails
Der größte Mehrwert topologiegetriebener Automation ist Policy-Generierung. Statt Policies manuell pro Router zu schreiben, leiten Sie sie aus Beziehungen ab: ein Neighbor ist „Transit“, ein anderer „Peer“, ein dritter „Customer“. Ein Interface ist „untrusted Edge“, ein anderes ist „Core“. Daraus entstehen automatisch Import/Export-Filter, LocalPref, Max-Prefix, CoPP-Klassen, und Security-Zonen.
- BGP Policies: Import/Export je Peer-Typ, Communities, Prepends, no-transit Regeln, RPKI/IRR-Checks (wo genutzt).
- Control-Plane Protection: CoPP Profile je Rolle, Management-Rate-Limits, erlaubte Protokolle pro Interface-Klasse.
- DDoS Policies: RTBH/FlowSpec Scope, autorisierte Quellen, Expiry by default, Containment pro Region.
- QoS Policies: Einheitliches Klassenmodell, aber rollenbasierte Umsetzung an Engpässen (WAN, DCI, Interconnect).
- Segmentation: VRFs, Security Domains, Jump-Zones und erlaubte Flows zwischen Zonen.
Anti-Pattern: Policies als Copy-Paste Artefakte
Copy-Paste skaliert nicht und erzeugt Drift. Wenn Policies aus Topologiebeziehungen abgeleitet werden, sind sie konsistent und auditierbar.
Pre-Checks: Validierung bevor etwas ins Netz geht
Topologiegetriebene Automation sollte Änderungen stoppen, bevor sie Schaden anrichten. Pre-Checks prüfen Datenqualität (SoT), Kompatibilität (Blueprint/Versionen) und Risiko (Blast Radius). In Telco-Netzen ist das besonders wichtig, weil ein fehlerhafter Exportfilter oder eine falsche MTU großflächige Effekte haben kann.
- Datenvalidierung: Pflichtfelder vorhanden, IDs konsistent, keine IP/VLAN-Kollisionen, Namensschema korrekt.
- Policy-Checks: Default-deny Regeln vorhanden, Max-Prefix gesetzt, Export-Whitelist aktiv.
- Topology-Risk: Welche Maintenance Domains sind betroffen? Gibt es SRLG-Kollisionen? Ist N-1 Headroom plausibel?
- Vendor/Version Matrix: Unterstützte Softwarestände und Interop-Profile eingehalten.
Designregel: Pre-Checks müssen maschinenlesbar sein
Ein „Review im Kopf“ ist nicht reproduzierbar. Definieren Sie Regeln, die in jedem Change automatisch laufen – besonders bei Standard-Changes.
Post-Checks: Evidence-by-Design nach dem Deploy
Nach dem Ausrollen entscheidet die Realität. Post-Checks prüfen, ob das Netz so reagiert, wie erwartet: Sessions sind up, Routen sind korrekt, Konvergenz ist stabil, Queue-Drops bleiben im Budget, und SLOs bleiben grün. Besonders hilfreich ist die Kopplung an Failure Scenarios: Bei kritischen Changes wird ein kleiner, kontrollierter Drain oder ein Canary-Link-Test durchgeführt, um Resilienz zu bestätigen.
- Routing Health: IGP Adjacencies, BGP Sessions, Prefix-Counts, Route Policies aktiv, keine Anomalien.
- Path & MTU: PMTUD/MSS, Overhead (MPLS/SR/EVPN), keine selektiven Blackholes.
- QoS & Congestion: Queue-Drops pro Klasse, Portauslastung an Engpässen, ECMP/LAG Imbalance.
- Observability: Telemetry läuft, Labels korrekt, keine Datenlücken, Alerting im erwarteten Zustand.
Ein einfacher Nachweis-Frame
Das Ziel ist nicht nur „Konfig ist drauf“, sondern „Service ist nachweislich stabil“.
Drift-Detection und Reconciliation: So bleibt die Topologie konsistent
In realen Telco-Netzen gibt es Notfälle und manuelle Eingriffe. Drift entsteht, wenn diese Änderungen nicht zurück in die SoT fließen. Deshalb braucht Automation eine Reconciliation-Strategie: Was ist der Soll-Zustand (SoT), was ist der Ist-Zustand (Netz), und wie wird differenziert zwischen „autorisierter Abweichung“ und „ungeplante Drift“?
- Ist/Soll Vergleich: Interfaces, IPs, VRFs, BGP Neighbors, Policies, CoPP/QoS Profile.
- Change-ID Korrelation: Abweichung ohne zugehörige Change-ID ist hochriskant.
- Drift Response: Automatisches Ticket, Alarm oder auto-remediate (nur in klaren, sicheren Fällen).
- Post-Incident Sync: Runbook-Schritt: Notfalländerungen werden innerhalb definierter Zeit in SoT/Git nachgezogen.
Anti-Pattern: Auto-Remediation ohne Guardrails
Automatisches „Zurücksetzen“ kann im Incident den Schaden vergrößern. Auto-Remediation funktioniert nur für klar definierte, ungefährliche Abweichungen – ansonsten ist ein kontrollierter Workflow besser.
Progressive Rollouts: Canary, Wellen und Rollback als Standard
Topologiegetriebene Automation reduziert Fehler, aber sie eliminiert sie nicht. Deshalb braucht jede Plattform progressive Rollouts: erst Canary, dann kleine Batches, dann breite Wellen. Topologie ist dabei der Schlüssel zur richtigen Gruppierung: Maintenance Domains, Regionen, Linkklassen, Servicekanten. Rollback muss geplant und getestet sein, bevor die nächste Welle startet.
- Canary Domains: Repräsentative Sites/PoPs mit begrenztem Blast Radius, aber realer Last.
- Wellen nach Topologie: Regionweise oder PoP-Paare; keine gleichzeitige Wartung redundanter Pfade.
- Stop/Go Gates: SLO/SLI, Queue-Drops, Prefix-Counts, Control-Plane Health entscheiden automatisch über Fortsetzung.
- Rollback-Readiness: Reversibilität (auch für Policies), Versionierung und schnelle Rückkehr zum sicheren Zustand.
Designregel: Topologie bestimmt die Rollout-Grenzen
Wenn Rollouts nach Organigramm geplant werden, kollidieren sie oft mit realen Failure Domains. Nutzen Sie Maintenance Domains aus L1/L2/L3 als harte Grenzen.
Vendor-übergreifende Automation: Einheitlicher Intent, unterschiedliche Render-Targets
Multi-Vendor-Topologien profitieren besonders von einem SoT- und Intent-Ansatz. Der Intent ist gleich (z. B. „Interconnect Edge mit Max-Prefix und no-transit“), aber die Renderlogik ist vendor-spezifisch. Entscheidend ist ein stabiler Datenvertrag, plus eine getestete Version-Matrix pro Vendor. So vermeiden Sie, dass „Automation“ zu einem unübersichtlichen Set an Spezialfällen wird.
- Intent-Model: Rollen, Policies, Serviceobjekte bleiben gleich, unabhängig vom Vendor.
- Renderer pro Vendor: Übersetzt Intent in CLI/API, mit konsistenten Semantiken und Validierungen.
- Interop-Guardrails: Timerprofile, MTU, BFD-Profile und BGP-Optionen als Blueprint, nicht als Vendor-Default.
- Telemetry-Contract: Pflichtmetriken und Labels, unabhängig vom Hersteller (gNMI/OpenConfig wo möglich).
Anti-Pattern: „Wir automatisieren Vendor A, Vendor B später“
Wenn die Intent- und Datenmodelle nicht von Anfang an vendor-neutral sind, entsteht Lock-in in der Automationsschicht. Bauen Sie den Datenvertrag vendor-neutral, auch wenn Sie mit einem Vendor starten.
Security-by-Design: Automatisierung als Guardrail, nicht als Risiko
Automation kann Security verbessern, indem sie Standards konsequent umsetzt: CoPP-Profile, Management-Segmentierung, Exportfilter, RPKI/IRR-Policies, RTBH/FlowSpec Governance, Jump-Zones, und Auditability. Gleichzeitig kann Automation Security verschlechtern, wenn sie falsche Defaults großflächig ausrollt. Deshalb braucht es Security-Gates im Pipeline-Design.
- Policy Baselines: Default-deny an Domänengrenzen, Max-Prefix, no-transit, CoPP je Rolle.
- Secrets Handling: Schlüssel und Credentials nicht im SoT „frei texten“, sondern über sichere Secret Stores (Prinzipien).
- Audit Trail: Jede Änderung mit Change-ID, Owner, Diff, und nachvollziehbarer Renderlogik.
- Least Privilege: Automation-Accounts mit minimalen Rechten, getrennt nach Domänen.
Designregel: Security Checks als Pflicht im CI
Wenn Policies aus Topologie generiert werden, können Sie Security-Regeln automatisch prüfen: z. B. „kein Export interner Prefixe“, „Max-Prefix gesetzt“, „RTBH nur aus autorisierter Quelle“.
Typische Stolpersteine und wie man sie vermeidet
- SoT-Daten unvollständig: Lösung: Pflichtfelder, Definition of Done pro Objektklasse, automatische Validierungen.
- Zu viele Sonderfälle: Lösung: Blueprints und Ausnahmeprozesse mit Ablaufdatum; Sonderfälle als bewusste Entscheidung.
- Keine Post-Checks: Lösung: Automatisierte Health- und Policy-Validierung; SLO-Gates statt „konfig ist drauf“.
- Drift wird ignoriert: Lösung: Ist/Soll-Abgleich, Change-ID Korrelation, Post-Incident Sync als Pflicht.
- Blast Radius zu groß: Lösung: Canary, progressive Rollouts, Maintenance Domains als Grenzen, Rollback-Readiness.
- Automation = Lock-in: Lösung: vendor-neutraler Datenvertrag, Renderer pro Vendor, Interop-Matrix.
- Telemetry saturiert Links: Lösung: Limits, Sampling, Batching, Rollenprofile (besonders Remote Sites).
Praktische Leitlinien: Topologie als Input für Provisioning und Policies
- Source of Truth etablieren: NetBox/CMDB als verbindliche Datenquelle mit klarer Datenhoheit pro Attribut.
- Layer-Datenmodell nutzen: L1/L2/L3/Services getrennt modellieren und über stabile IDs verknüpfen.
- Rollen und Linkklassen definieren: Core/Edge/PE/BNG, IXP/PNI/Transit/DCI/WAN – Grundlage für Templates und Policies.
- Blueprints bauen: Minimales, getestetes Feature-Set pro Rolle; inklusive verbotener Features und Guardrails.
- Policies ableiten: Import/Export, CoPP, QoS, DDoS-Mitigation, Segmentation aus Topologiebeziehungen generieren.
- Pre-Checks verpflichtend: Datenvalidierung, Risikoanalyse (Failure Domains), Version-Matrix und Policy-Checks vor Deploy.
- Post-Checks automatisieren: Routing Health, MTU, QoS, SLOs und Observability nach Deploy nachweisen.
- Drift Detection betreiben: Ist/Soll-Vergleich, Change-ID Korrelation, kontrollierte Reconciliation.
- Progressive Rollouts standardisieren: Canary → Batch → Wellen, Stop/Go Gates, getesteter Rollback.
- Dokumentation und Audit sichern: Diffs, Change-IDs, Renderlogik und Ergebnisse („Expected vs. Observed“) versioniert ablegen.
