4. Der Source of Truth#

Ein neuer Dienst musste bis Ende der Woche in Betrieb gehen. Die Änderung war unkompliziert: ein neues VLAN, ein neues Subnetz, aktualisierte Firewall-Regeln und eine neue BGP-Community auf den Edge-Routern. Der Netzwerktechniker wusste genau, was zu tun war. Was folgte, waren vier Tage Koordination über fünf Systeme hinweg: das IPAM-Tool zur Reservierung des Subnetzes, die CMDB zur Registrierung des Dienstes, die Firewall-Verwaltungsplattform zum Einreichen der neuen Richtlinie, das Router-Konfigurationssystem für die BGP-Community und die Monitoring-Plattform zum Hinzufügen der neuen Schwellenwerte. Jedes System hatte seine eigene Schnittstelle, sein eigenes Datenmodell, seinen eigenen Genehmigungsworkflow. Und da es keine gemeinsame Referenz gab, musste der Ingenieur den Kontext manuell mitführen: Werte von einem System zum nächsten kopieren und hoffen, dass zwischen den Schritten nichts abweicht.

Sechs Monate später wurde der Dienst stillgelegt. Das VLAN wurde entfernt. Das Subnetz wurde freigegeben. Aber die Firewall-Regel blieb. Niemand erinnerte sich, dass sie mit diesem Dienst verknüpft war. Die BGP-Community blieb auf zwei Edge-Routern. Der Monitoring-Schwellenwert feuerte weiter Low-Priority-Alarme, die das NOC gelernt hatte zu ignorieren. Im Laufe der Zeit häufte das Netzwerk Schichten verwaister Konfiguration an: Überreste von Änderungen, die nie vollständig nachverfolgt, nie vollständig rückgängig gemacht und nie mit einem gemeinsamen Absatzdatensatz verbunden wurden.

So sieht der Betrieb eines Netzwerks ohne Source of Truth tatsächlich aus. Kein einzelner dramatischer Ausfall, sondern eine langsame Ansammlung von Inkonsistenzen, bei der jede Änderung mehrere getrennte Systeme aktualisieren muss und nichts nachverfolgt, was zusammengehört.

Jedes Automatisierungssystem beginnt mit einer Frage: Was werde ich eigentlich tun? Wenn man eine Firewall-Regel bereitstellt, eine IP-Adresse hinzufügt oder ein VLAN konfiguriert, geschieht das auf Basis einer Darstellung der Absicht. Diese Darstellung ist der Source of Truth: die einzige, zuverlässige Version dessen, was bereitgestellt werden soll.

Ich verwende „Source of Truth" und „Intent" gleichbedeutend. Es handelt sich um exakt dasselbe Konzept.

Ohne einen zuverlässigen Source of Truth werden Netzwerkoperationen zu einem Chaos aus Stammwissen. Ingenieure sind sich uneinig darüber, was bereitgestellt ist. Tabellenkalkulationen widersprechen dem, was tatsächlich läuft. Zwei verschiedene Automatisierungssysteme nehmen widersprüchliche Änderungen am selben Gerät vor. Wenn etwas kaputt geht, betreibt man Archäologie: „Warum war das so konfiguriert? Wer hat es genehmigt? Wann hat es sich geändert?"

Dieses Kapitel untersucht, wie man einen Source of Truth aufbaut, der funktioniert, egal ob man Dutzende oder Hunderttausende von Geräten hat, der allen Beteiligten Zugang zu den Daten bietet (Menschen, Automatisierung, andere Systeme), der die Daten genau und vertrauenswürdig hält und der die Komplexität des Datenbezugs aus mehreren Quellen handhabt. Wir behandeln sechs Bausteine: Modellierung, Design-Driven, Konsum, Durchsetzung, Versionierung und Aggregation, die zusammen ein solides Fundament für die Netzwerkautomatisierung bilden. Ich werde auch auf praktische Fragen beim Einbeziehen bestehender Netzwerke in dieses System eingehen und zeigen, welche Lösungen tatsächlich verfügbar sind.

4.1. Grundlagen#

Der Source of Truth tut drei Dinge: Er definiert, wie man ausdrückt, was man möchte, wo diese Absicht liegt und wie man sie über die Zeit vertrauenswürdig hält. Ohne ihn werden die anderen Bausteine zu eigenständigen Tools ohne gemeinsame Referenz. Mit ihm arbeiten sie zusammen.

4.1.1. Ziele#

Ein Source of Truth muss sechs Dinge tun:

1. Alles erfassen, was benötigt wird. Das vollständige Bild des Netzwerks speichern: Konfigurationen, Assets, Topologie, Dienste, IP-Adressen, Leitungen, Gerätespezifikationen, Geheimnisse, Wartungsfenster, Compliance-Anforderungen und wer was besitzt. Nicht nur das, was heute läuft, sondern auch das Geplante und das Außerbetriebgestellte. Wenn all diese Daten an einem Ort statt verstreut über Tabellenkalkulationen und Köpfe leben, haben die Automatisierungssysteme tatsächlich den Kontext, den sie für fundierte Entscheidungen benötigen.

2. Betreiber in Geschäftsbegriffen denken lassen, nicht in Gerätesyntax. Mitarbeiter sollten auf der Geschäftsebene arbeiten („neue Zweigstelle hinzufügen" oder „MPLS-Dienst einrichten"), nicht auf der Command Line Interface (CLI)-Ebene. Im Hintergrund ermittelt das System die tatsächlichen gerätespezifischen Konfigurationen. Das hält die Menschen fokussiert auf das, was sie erreichen wollen, nicht auf Low-Level-Details.

3. Menschen und Maschinen einfachen Datenzugang ermöglichen. Das System benötigt Application Programming Interface (API)s (Representational State Transfer (REST), GraphQL), damit Automatisierung Daten abrufen und ändern kann. Es braucht eine Web-UI und eine Command Line Interface (CLI), damit Menschen Daten durchsuchen und bearbeiten können. Jeder braucht solide Zugriffskontrollen, damit er nur sieht, was er sehen sollte. Hundert Automatisierungsworkflows können gleichzeitig laufen, Dutzende Mitarbeiter Daten bearbeiten und externe Systeme synchronisieren, und alles bleibt konsistent und schnell.

4. Daten sauber und vertrauenswürdig halten. Alles validieren: prüfen, ob Datentypen korrekt sind, Beziehungen sinnvoll sind, VLANs im gültigen Bereich liegen, IP-Adressen sich nicht wiederholen. Nachverfolgen, wer was wann geändert hat. Wichtige Änderungen vor der Übernahme genehmigen lassen. Wenn etwas schiefgeht, kann man zurückrollen. Die Automatisierung muss darauf vertrauen, dass die Daten korrekt sind, denn schlechte Daten führen zu schlechtem Netzwerkzustand und Ausfällen.

5. Paralleles Arbeiten ohne gegenseitige Behinderung ermöglichen. Mehrere Teams sollten gleichzeitig Änderungen vorschlagen können. Änderungen werden in atomare Bündel gruppiert: Entweder gehen alle rein oder alle schlagen fehl, keine Halbzustände. Änderungen können in einer Staging-Umgebung getestet werden, bevor sie live gehen. Bei großen Migrationen kann man abzweigen, die Arbeit erledigen und wieder zusammenführen. Man weiß immer, welche Absicht gerade verwendet wird versus was vorgeschlagen wird.

6. Daten aus anderen Systemen einbinden. Wahrscheinlich gibt es bereits Asset-Management für Hardware, IP-Systeme für Adressen, Leitungsanbieter für Konnektivität, CMDBs für Dienste. Diese nicht duplizieren. Stattdessen synchronisieren. Klare Regeln festlegen, welches System welche Daten besitzt. Alles in beide Richtungen synchron halten. So erhält man eine einheitliche Sicht auf alles, ohne das Rad neu zu erfinden.

4.1.2. Säulen#

Diese sechs Säulen sind keine unabhängigen Funktionen; sie bilden eine Schichtarchitektur. Modellierung definiert, was ausgedrückt werden kann. Design-Driven übersetzt diesen Ausdruck in technische Artefakte. Konsum macht diese Artefakte für jedes System verfügbar, das sie benötigt. Durchsetzung hält die Daten beim Eingang vertrauenswürdig. Versionierung bewahrt die Absichtshistorie über die Zeit und ermöglicht Rollback und Prüfung. Aggregation verhindert, dass der SoT zu einem weiteren isolierten Silo wird, indem autoritative Daten aus den Systemen eingezogen werden, die sie bereits besitzen.

Entfernt man eine davon, verschlechtern sich die anderen. Ohne Durchsetzung liefert der Konsum schlechte Daten. Ohne Versionierung gibt es keine Möglichkeit, nachzuvollziehen, was sich geändert hat, wenn etwas kaputt geht. Ohne Aggregation pflegen Betreiber doppelte Daten über Systeme hinweg und der SoT verliert das Vertrauen. Abschnitt 4.2 behandelt jede davon ausführlich.

Bevor wir die sechs Funktionalitäten im Detail betrachten, klären wir, was in den Verantwortungsbereich des Source of Truth fällt.

4.1.3. Umfang#

Bevor man sich mit Implementierungsdetails befasst, ist es wichtig zu verstehen, wofür der Source of Truth verantwortlich ist und wofür nicht.

Im Geltungsbereich:

Der Source of Truth verwaltet alle Absichtsdaten: die vollständige Definition dessen, wie das Netzwerk aussehen soll. Das umfasst Produktionskonfigurationen, Staging-Umgebungen, Entwicklungszweige und Testszenarien. Alles, was „was man will" beschreibt, lebt hier.

Außerhalb des Geltungsbereichs:

Der Source of Truth tut mehrere Dinge nicht, die möglicherweise verwandt erscheinen:

1. Observability-Daten: Der Source of Truth speichert keine Metriken, Logs oder Laufzeitzustände. Er definiert jedoch die Erwartungen, mit denen man vergleicht, wie Schwellenwerte für Alarme oder Basis-Leistungszahlen. Die tatsächlichen Observability-Daten leben woanders (behandelt in Kapitel 6).

2. Netzwerkinteraktion: Der Source of Truth spricht nicht mit Geräten und überträgt keine Konfigurationen. Er stellt die notwendigen Artefakte bereit (Gerätekonfigurationen, Validierungsregeln, Deployment-Manifeste), führt sie aber nicht aus. Das ist die Aufgabe des Executors (Kapitel 5).

3. Orchestrierungslogik: Der Source of Truth definiert keine Schrittfolgen oder Workflows für die Bereitstellung von Änderungen. Er definiert den beabsichtigten Endzustand. Wie man dorthin gelangt (welche Geräte zuerst, welche Validierungsschritte, Rollback-Verfahren) gehört zum Orchestrator (Kapitel 7).

Denken Sie an den Source of Truth als den Nordstern für die Netzwerkautomatisierungsstrategie. Er ist die einzige, autoritative Antwort auf „Wie soll das Netzwerk aussehen?" Alles andere im Automatisierungssystem (Ausführung, Monitoring, Orchestrierung) referenziert diese Wahrheit, um seine Aufgabe zu erfüllen. Wenn die Realität von der Absicht abweicht, sagt der Source of Truth, was die Realität werden sollte.

4.2. Funktionalitäten#

Sprechen wir nun über die sechs Funktionalitäten, die das alles tatsächlich implementieren.

Jede entspricht einem Ziel und einer Säule:

1. Modellierung: Definiert, welche Daten gespeichert werden und wie sie zusammenhängen. Gerätemodelle, Schnittstellen, VLANs, Leitungen, Dienste. Lässt sie sich weiterentwickeln, wenn sich die Anforderungen ändern.

2. Design-Driven: Übersetzt übergeordnete Absicht durch Vorlagen und Logik in tatsächliche Gerätekonfigurationen.

3. Konsum: Wie Menschen und Systeme tatsächlich auf die Daten zugreifen und sie verwenden. Application Programming Interface (API)s, Web-UI, Command Line Interface (CLI). Jeder erhält eine seiner Rolle angepasste Zugriffskontrolle.

4. Durchsetzung: Stellt sicher, dass keine schlechten Daten einschleichen. Validierung, Eindeutigkeitsprüfungen, referenzielle Integrität. Klare Fehlermeldungen.

5. Versionierung: Führt die vollständige Historie. Wer hat was wann und warum geändert. Bei Bedarf zurückrollen.

6. Aggregation: Zieht Daten aus anderen Systemen (CMDB, IPAM usw.) ein und hält sie synchronisiert.

graph LR

    %% --- Subgraphs ---
    subgraph Goals
        direction TB
        A1[Alles erfassen, was benötigt wird]
        A2[Betreiber in Geschäftsbegriffen denken lassen, nicht in Gerätesyntax]
        A3[Menschen und Maschinen einfachen Datenzugang ermöglichen]
        A4[Daten sauber und vertrauenswürdig halten]
        A5[Paralleles Arbeiten ohne gegenseitige Behinderung ermöglichen]
        A6[Daten aus anderen Systemen einbinden]
    end

    subgraph Pillars
        direction TB
        B1[Flexibles Datenmodellierungs-Framework]
        B2[Design und Vorlagen]
        B3[APIs und Schnittstellen]
        B4[Datenvalidierung]
        B5[Änderungshistorie]
        B6[Datenaggregation]
    end

    subgraph Functionalities
        direction TB
        C1[Modellierung]
        C2[Design-Driven]
        C3[Konsum]
        C4[Durchsetzung]
        C5[Versionierung]
        C6[Aggregation]
    end


    %% --- Row connections ---
    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5
    A6 --> B6 --> C6

    %% --- Row gradient classes ---
    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;
    classDef row6 fill:#80bfff,stroke:#4a90e2,stroke-width:1px;

    %% --- Apply classes per row ---
    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;
    class A6,B6,C6 row6;

Im Folgenden eine architektonische Perspektive des Intent-Bausteins:

graph TB

    %% Tier 1
    subgraph T1[Extern]
        A[Konsum]
    end

    %% Tier 2
    subgraph T2[Daten]
        B[Design-Driven]
        D[Modellierung]
    end

    %% Tier 3
    subgraph T3[Engine]
        C[Aggregation]
        E[Durchsetzung]
        F[Versionierung]
    end

    %% Tier connections
    A <--> B
    A <--> D

    B <--> D

    D <--> C
    D <--> E
    D <--> F

4.2.1. Modellierung#

Das Datenmodell ist entscheidend: Es bestimmt, was dargestellt werden kann und wie einfach damit gearbeitet werden kann. Wie George Box feststellte: „Alle Modelle sind falsch, aber manche sind nützlich." Es gibt kein perfektes Modell, das für alle funktioniert. Meiner Erfahrung nach ist Datenmodellierung mehr Kunst als Wissenschaft. Aber bestimmte Muster tauchen in erfolgreichen Projekten immer wieder auf.

4.2.1.1. Grundprinzipien#

Wie Daten organisiert werden, ist entscheidend. Es bestimmt, was ausgedrückt werden kann und wie effizient Systeme es validieren und nutzen können. Verschiedene Formate haben verschiedene Kompromisse. YAML ist lesbar, validiert aber wenig. JavaScript Object Notation (JSON) funktioniert überall, ist aber ausführlich. Yet Another Next Generation (YANG) fügt Validierung hinzu, hat aber eine steile Lernkurve. Die Wahl sollte auf dem basieren, was tatsächlich gebraucht wird.

Daten existieren auf verschiedenen Ebenen. Dasselbe Netzwerkstück kann für verschiedene Zwecke auf mehrere Arten beschrieben werden:

• Dienstebene: Geschäftsfreundlich („MPLS L3VPN für Zweigstelle X einrichten")
• Technische Ebene: Technische Spezifikationen („BGP AS 65001, Route Targets 65001:100, Richtlinien…")
• Geräteebene: Tatsächliche Konfigurationen („interface xe-0/0/0; unit 100;…")

Gute Modelle verbinden diese Schichten. Man kann auf Geschäftsebene beginnen und dann Gerätekonfigurationen automatisch generieren. Aber man braucht nicht immer alle drei Schichten: Das hängt davon ab, was gebaut wird.

4.2.1.2. Datenpersistenz und Skalierung#

Die Wahl der Datenspeicherung des Modells hat tiefgreifende Auswirkungen auf Konsistenz, Leistung und Weiterentwicklung. Diese Auswirkungen werden kritisch, wenn das Netzwerk von Hunderten auf Hunderttausende verwaltete Objekte wächst.

• Relationale Datenbanken (z.B. MySQL, PostgreSQL): Das ist die sichere Wahl für die meisten Teams, und ich meine das als Kompliment. Sie erzwingen Schema-Konsistenz, bieten ACID-Transaktionen und jeder Ingenieur im Team kennt bereits SQL. Sie zeichnen sich durch die Darstellung normalisierter Hierarchien (VLANs mit Schnittstellen) aus und verhindern Datenanomalien. Der Nachteil: Schema-Änderungen schmerzen bei großem Maßstab, und die Leistung bricht bei tiefen Joins über Millionen von Zeilen ein. Aber das ist ein gutes Problem: Es bedeutet, dass man tatsächlich etwas bereitgestellt hat.

• Dokumentendatenbanken (z.B. MongoDB, CouchDB): Hervorragend, wenn Schema-Flexibilität und horizontale Skalierbarkeit benötigt werden. Dokumente modellieren natürlich verschachtelte Strukturen (ein Gerät mit allen seinen Konfigurationen und Metadaten als ein Blob). Aber hier ist der Haken: Man ist nun für die Konsistenz über Dokumente hinweg verantwortlich, und komplexe Abfragen werden schnell teuer. Ohne einen spezifischen Grund für den dokumentenbasierten Ansatz sollte man bei relationalen Datenbanken bleiben.

• Graphdatenbanken (z.B. Neo4j): Diese sind wirklich besser, wenn Beziehungen wichtiger sind als Objekte: „Welche VLANs verbindet diese Schnittstelle? Welche Geräte routen zwischen diesen zwei Standorten?" Sie traversieren Beziehungen beliebiger Tiefe effizient. Aber wenn keine ständigen komplexen Topologieabfragen durchgeführt werden, wählt man die exotische Option. Das Ops-Team kennt sie nicht, das Tooling ist weniger ausgereift und die Schreibleistung hinkt bei einfachen Updates hinterher. Graphdatenbanken lösen echte Probleme, aber man sollte sicherstellen, dass diese Probleme tatsächlich vorhanden sind.

flowchart TD
    Q1{Hauptanforderung?}
    Q1 -->|Komplexe Beziehungen in der Tiefe traversieren| Q2{Ständige Topologie-Abfragen?}
    Q1 -->|Schema entwickelt sich häufig weiter| DB_D[Dokumentenspeicher]
    Q1 -->|Strukturierte Abfragen, referenzielle Integrität| DB_R[Relationale Datenbank]
    Q2 -->|Ja| DB_G[Graph-Datenbank]
    Q2 -->|Gelegentlich| DB_R

    style DB_R fill:#ccffcc,stroke:#28a745
    style DB_G fill:#cce5ff,stroke:#4a90e2
    style DB_D fill:#ffffcc,stroke:#ffc107

Mehr über Datenpersistenz aus einer anderen Perspektive im Observability-Kapitel.

Die Datenbankauswahl ist eines der wichtigsten Unterscheidungsmerkmale zwischen Produkten in diesem Bereich. Zum Beispiel verwenden NetBox und Nautobot relationale Datenbanken, während Infrahub eine Graphdatenbank verwendet, wie in Abschnitt 4.2.8 zu sehen ist.

Persistenz kann auch mit dateibasiertem Speicher und Datenmodellen wie YAML oder JavaScript Object Notation (JSON) (oder CSV) implementiert werden, die üblicherweise in Git-Systemen zur Versionskontrolle verwaltet werden.

Die meisten produktiven Source-of-Truth-Systeme verwenden polyglotte Persistenz: eine relationale Datenbank für autoritative Absichten und Beziehungen, Dokumentenspeicherung oder Git für Flexibilität und Caching, und Graph-Fähigkeiten für die Topologieanalyse.

Wie granular sollte das Modell sein? Das ist wichtig für die Leistung. Wenn jede Schnittstelle auf jedem Gerät als separates Objekt modelliert wird, erhält man 50.000+ Objekte für ein mittleres Netzwerk. Abfragen werden langsam. Updates schmerzhaft.

Der praktische Ansatz: Vorlagen für häufige Muster verwenden. Zum Beispiel „Schnittstellen 1-40 verwenden diese Standardvorlage" und nur Ausnahmen verfolgen. Das sind 2 Objekte statt 40, Abfragen bleiben schnell und das Rendering funktioniert trotzdem.

In Kapitel 11 werden wir mehr darüber behandeln, wie solche Entscheidungen die Leistung beeinflussen.

4.2.1.3. Netzwerk-Datendomänen#

Umfassende Source-of-Truth-Implementierungen modellieren typischerweise diese miteinander verbundenen Domänen:

• Inventar und Assets: Physische und logische Geräte, Hardware-Spezifikationen, Seriennummern, Beschaffungsdatum, Vertragsbedingungen, Lebenszyklusphase
• Rechenzentrum-Infrastruktur: Standorte (geografisch und hierarchisch), Gebäude, Etagen, Räume, Racks, Stromverteilung, Kabelführungen
• IP-Adressverwaltung (IPAM): Adresspools, Subnetze, Zuteilungen, DNS-Auflösung, DHCP-Bereiche, Nutzungsverfolgung
• Virtualisierung und Cloud: VPCs, Subnetze, Sicherheitsgruppen, Compute-Instanzen, Storage, Container-Orchestrierungsbeziehungen
• Konnektivität: Physische Leitungen (MPLS, Ethernet), virtuelle Tunnel, Peering-Beziehungen, Bandbreitenzuteilungen, QoS-Richtlinien
• Routing: BGP-Communities, autonome Systeme, Routing-Richtlinien, Präfixlisten, Route Targets für L3VPN-Dienste
• Dienste: Logische Dienstdefinitionen (L3VPN, L2VPN, Firewall-Traversierung), Dienst-zu-Gerät-Zuordnungen, SLAs
• Sicherheit und Compliance: Zugriffskontrolllisten, Firewall-Regeln, Sicherheitszonen, Compliance-Tags, Prüfungsanforderungen
• Management: SNMP-Details, gNMI-Abonnements, NTP-Quellen, Syslog-Ziele, TACACS+/RADIUS-Integration

Diese Domänen sind voneinander abhängig: Routing referenziert Konnektivität, Dienste erstrecken sich über Inventar und IPAM, Sicherheitsrichtlinien gelten für sowohl Geräte als auch Dienste. Ein gut entworfener SoT modelliert diese Beziehungen explizit, statt jede Domäne als isolierte Tabelle zu behandeln.

graph TD
    INV[Inventar und Assets]
    DC[RZ-Infrastruktur]
    IPAM[IP-Adressverwaltung]
    VIRT[Virtualisierung und Cloud]
    CONN[Konnektivität]
    ROUTE[Routing]
    SVC[Dienste]
    SEC[Sicherheit und Compliance]
    MGMT[Management]

    DC --> INV
    INV --> IPAM
    INV --> MGMT
    CONN --> INV
    VIRT --> IPAM
    ROUTE --> CONN
    SVC --> INV
    SVC --> ROUTE
    SVC --> IPAM
    SEC --> INV
    SEC --> SVC

    classDef foundation fill:#ddeeff,stroke:#4a90e2,stroke-width:2px
    classDef overlay fill:#e8f5e9,stroke:#28a745
    classDef policy fill:#fff3cd,stroke:#ffc107
    class INV,IPAM,CONN foundation
    class ROUTE,VIRT,DC,MGMT overlay
    class SVC,SEC policy

Neben netzwerkspezifischen Domänen werden viele andere Datentypen benötigt. Zum Beispiel ein Secrets-Backend zur Speicherung von Anmeldedaten. Allgemeiner gesagt fügt sich umfassendes Datenmanagement in ein globales IT-Infrastruktur-Managementsystem ein.

Ich möchte eine häufige Frage ansprechen, die viele Teams beschäftigt, die zwischen einer netzwerkspezifischen Datenquelle wie NetBox und einer allgemeinen wie ServiceNow abwägen. Meiner Erfahrung nach ist es zwar möglich, ähnliche Ergebnisse zu erzielen, aber die Tatsache, dass ServiceNow ein unternehmensweites System ist, macht es schwieriger (und langsamer), es weiterzuentwickeln, was Netzwerkteams ausbremst, wenn sie es für eine vollständige Netzwerkdarstellung nutzen wollen.

Datenklassifizierung und gemeinsame Attribute

In Netzwerkdomänen tauchen bestimmte Klassifizierungsmuster konsistent auf. Gut entworfene Modelle umfassen diese grundlegenden Attribute für eine konsistente Datenmanipulation:

• Rolle: Welchem Zweck dient dieses Objekt? (Core, Distribution, Access; primär, sekundär)
• Status: Ist es aktiv, geplant, außer Betrieb gesetzt oder stillgelegt?
• Art: Um welchen Objekttyp handelt es sich? (VLAN, Gerät, Leitung, Dienst)
• Eigentümerschaft: Welches Team oder welche Geschäftseinheit verwaltet das?
• Standort: Wo befindet sich diese Ressource geografisch oder organisatorisch?

4.2.1.4. Modelldesign-Muster: Erweiterbarkeit, Polymorphismus und Migrationen#

Manche Lösungen werden mit einem eingebauten Modell geliefert, das auf der Vorstellung der Ersteller basiert, wie Netzwerke aussehen sollten. Das ist hervorragend, wenn das eigene Netzwerk dieser Annahme entspricht, und nicht so gut, wenn nicht. Andere Lösungen erlauben es, alles von Grund auf aufzubauen: große Flexibilität, aber man braucht Disziplin. Normalerweise ist der beste Ansatz ein Hybrid: die eingebauten Modelle für häufige Fälle verwenden (die 80%, die alle haben), aber sicherstellen, dass sie für spezifische Bedürfnisse erweitert werden können.

Das Spektrum: Von dogmatisch bis vollständig angepasst

Es gibt hier ein Spektrum, und es lohnt sich zu verstehen, wo man sich befindet:

• Stark dogmatische Modelle (z.B. NetBox von der Stange):

  • Vorteile: Schnell bereitzustellen, weniger Entscheidungsaufwand, eingebaute Best Practices
  • Nachteile: Schmerzhaft, wenn das Netzwerk nicht in die Form passt, Modelländerungen sind schwierig

• Vollständig angepasste Modelle (von Grund auf selbst erstellen, wie Infrahub):

  • Vorteile: Perfekte Passung für spezifische Bedürfnisse, keine verschwendeten Felder
  • Nachteile: Extra Zeit für das Design, viel Versuch und Irrtum, niemand, von dem man kopieren kann (aber es gibt Referenzen)

Auch wenn Infrahub vollständig angepasste Modelle erlaubt, liefert es auch dogmatische Modelle als Einstiegspunkt.

Wo sollte man tatsächlich beginnen? Was ich jedem sage: Mit Tools mit dogmatischen Modellen wie NetBox, Nautobot oder Infrahub beginnen. Punkt. Egal wie besonders das eigene Netzwerk ist. Die Teams, die „wir bauen unser eigenes perfektes Modell" sagen, modellieren noch zwei Jahre später, während diese Tool-Teams vor vielen Monaten gültige Modelle ausgeliefert haben.

Man ist nicht Google (oder vielleicht doch?). In vielen Fällen baut man keine Hyperscale-Cloud. Was existiert verwenden, erweitern, wenn echte Grenzen erreicht werden (nicht vorgestellte), und etwas liefern, das funktioniert.

Wenn natürlich bereits absehbar ist, dass ein sehr spezieller Netzwerkanwendungsfall vorliegt, kann man in Betracht ziehen, welches Tool ihn besser unterstützt, aber das Rad nicht von Tag eins vollständig neu erfinden.

Die einzige Entscheidung, die zählt: Kann man erweitern, ohne neu zu schreiben? Wenn das Hinzufügen eines benutzerdefinierten Feldes zur Verfolgung von „Kostenstelle" den Neuaufbau des gesamten Schemas erfordert, sollte man weglaufen. Wenn es in 20 Minuten als benutzerdefiniertes Attribut hinzugefügt werden kann, hat man das richtige Tool gefunden.

Man möchte 80% Standardisierung mit 20% Flexibilität (um die eigene spezifische Realität zu handhaben). Alles, was „unendlich flexibel" sein soll, wird unendlich Zeit zum Konfigurieren benötigen.

Polymorphismus: Ein Modell, viele Ausprägungen

Nicht alle Schnittstellen sind gleich. Ein physischer optischer Port und eine Tunnel-Schnittstelle haben einige gemeinsame Eigenschaften, aber sie sind unterschiedliche Gebilde. Man könnte vollständig separate Modelle für jedes erstellen, aber das wird schnell unübersichtlich und begrenzt die Nutzbarkeit.

Besserer Ansatz: Ein gemeinsames Basismodell definieren, das das Gemeinsame abdeckt, dann spezialisierte Varianten für die unterschiedlichen Details erstellen.

# Alle Schnittstellen teilen diese Grundlagen
interfaces:
  - name: "eth0"
    type: "physical"
    status: "up"
    mtu: 1500
    ipv4_address: "192.0.2.1/24"

# Ein physischer optischer Port hat zusätzliche Felder
  - name: "eth0"
    type: "physical_optical"
    status: "up"
    mtu: 1500
    ipv4_address: "192.0.2.1/24"
    optics_module: "100GBASE-LR4"
    tx_power_dbm: -2.5
    rx_power_dbm: -8.3
    laser_temperature: 48.2

# Und ein Tunnel sieht unter der Haube ganz anders aus
  - name: "tun-vpn-dallas"
    type: "tunnel_gre"
    status: "up"
    mtu: 1476
    ipv4_address: "10.0.0.1/30"
    tunnel_source: "203.0.113.1"
    tunnel_destination: "198.51.100.5"
    tunnel_encap: "GRE"
    tunnel_key: 100

Auf diese Weise können Skripte „alle Schnittstellen auf diesem Gerät" abfragen, ohne zu wissen, ob sie mit Optik oder Tunneln kommunizieren. Wenn aber optikspezifische Details benötigt werden (TX-Leistungswerte abrufen), kann man auf diese spezialisierten Felder zugreifen. Einen neuen Schnittstellentyp später hinzufügen? Kein Problem: einfach eine weitere Variante hinzufügen.

Modelle ändern sich: Dafür planen

Netzwerke leben Jahrzehnte. Das Modell wird nicht statisch bleiben. Neue Felder werden hinzugefügt, die Art und Weise, wie Dinge miteinander in Beziehung stehen, wird geändert, und nicht mehr funktionierendes wird veraltet. Aber man kann nicht einfach einen Schalter umlegen und alles, was auf dem alten Schema läuft, kaputt machen.

Die Herausforderung: Wenn das Modell sich ändert, kann sich viel Nachgelagertes kaputt gehen: Validatoren brauchen neue Regeln, APIs ändern, was sie zurückgeben, Datenbankabfragen setzen bestimmte Spalten voraus, Vorlagen brauchen andere Feldpfade, Berichte sind gegen die alte Struktur geschrieben. All das muss sich anpassen, oder zumindest nicht katastrophal kaputt gehen. So werden Änderungen ohne Chaos bewältigt:

• Dinge als veraltet markieren, bevor sie entfernt werden. Wenn ein Feld wegfällt, alle 2-3 Releases im Voraus informieren. Eine Übergangsfrist für die Migration geben.

• Feld-Aliase während des Übergangs unterstützen. Alter Code, der device_name abfragt? Im Hintergrund auf hostname umleiten. Die API funktioniert weiterhin, die Leute haben Zeit, ihre Automatisierung zu aktualisieren.

• Migrations-Helfer erstellen. Wenn Daten neu strukturiert werden (zum Beispiel Schnittstellen von einer flachen Liste zu verschachtelten unter Geräten verschieben), Skripte bereitstellen, die die Hauptarbeit übernehmen.

• Mit allem testen, was von den Daten abhängt. Vor dem Ausrollen von Schema-Änderungen:

  • Gibt die API Daten noch auf die alte Weise zurück? (über Aliase)
  • Rendern die Vorlagen noch?
  • Funktionieren die SQL-Abfragen noch?
  • Parsen die Integrationen mit externen Systemen noch, was sie empfangen?

• Gemischte Versionen in der Produktion für eine Weile erwarten. Große Organisationen haben oft Geräte auf drei verschiedenen Schema-Versionen gleichzeitig:

  150 Geräte auf Schema 1.9 (alt)
  300 Geräte auf Schema 2.0 (aktuell)
  50 Geräte auf Schema 2.1 (Beta-Test)

Das System muss alle drei ohne Unterbrechung handhaben. Diese Komplexität ist es wert: Netzwerke sind zu wichtig, um durch leichtfertige Schema-Änderungen kaputt zu gehen.

4.2.1.5. Konfigurationsvorlagen#

Vorlagen übersetzen abstrakte Absicht („Ich möchte ein VLAN") in tatsächliche Command Line Interface (CLI)-Befehle. Hier ist die wichtigste Regel: Vorlagen enthalten Logik, keine Daten. Die Vorlage sagt „verwende die VLAN-ID aus dem Datenmodell, gib sie hier aus". Die tatsächliche VLAN-ID kommt aus den Daten, nicht aus der Vorlage. Das hält Daten portabel und testbar. Jinja2 ist beliebt, weil es für Menschen lesbar, in Python und Ansible integriert und für echte Netzwerke praktisch ist. Es ist jedoch nicht die einzige Option – es gibt viele gültige Alternativen.

Gegeben zum Beispiel eine Datenstruktur für Schnittstellen:

interfaces:
  - name: Ethernet1
    description: Uplink to core
    enabled: true
  - name: Ethernet2
    description: Server port
    enabled: false

Und diese CLI-Konfigurations-Jinja2-Vorlage:

# Interfaces
{% for iface in interfaces %}
interface {{ iface.name }}
  description {{ iface.description }}
  {% if iface.enabled %}
  no shutdown
  {% else %}
  shutdown
  {% endif %}
{% endfor %}

Wird folgende CLI-Ausgabe erzeugt:

# Interfaces
interface Ethernet1
  description Uplink to core
  no shutdown
interface Ethernet2
  description Server port
  shutdown

Die klare Trennung zwischen Daten und dem Konfigurationsartefakt ist dabei erkennbar.

Eine interessante Alternative zu Jinja ist die deklarative Konfigurationssprache CUE, die mehrere Datenfunktionalitäten vereint:

• Rohdaten, wie YAML
• Datenvalidierung/Schema, wie JSON Schema (mehr im Durchsetzungsabschnitt)
• Dynamische Datengenerierung, wie Jinja

CUE behandelt Konfiguration als typisierte, zusammensetzbare Daten mit erzwungenen Invarianten statt als lose strukturierten Text (wie Jinja).

4.2.2. Design-Driven#

Bei 50 Geräten und 30 VLANs kann man sie einzeln verwalten: jedes VLAN erstellen, jede Schnittstelle konfigurieren, jede IP manuell zuweisen. Das ist mühsam, aber handhabbar.

Bei 5.000 Geräten und Hunderten von Diensten ist manuelle Verwaltung unmöglich. Das Hinzufügen einer neuen Zweigstelle würde bedeuten, 100+ Konfigurationselemente pro Standort manuell anzugeben. Der Design-Driven-Baustein löst das: Betreiber beschreiben, was sie auf hoher Ebene wollen („Zweigstelle hinzufügen"), und das System expandiert es zu vollständigen technischen Spezifikationen.

4.2.2.1. Von Geschäftsabsicht zu technischen Daten#

Beispielszenario – „Bürozweigstelle in Dallas hinzufügen":

Geschäftsabsicht (High Level):

{
  "type": "branch_office",
  "location": "dallas-tx",
  "site_code": "DAL-01",
  "circuit_count": 2,
  "employee_count": 50,
  "applications": ["erp", "voip", "video"]
}

Design-Verarbeitung

flowchart LR
    A[Geschäftsabsicht]
    B[Vorlage anwenden]
    C[Ressourcen zuweisen]
    D[Logik auflösen]
    E[Details rendern]
    F[Objekte für den Executor]

    A --> B --> C --> D --> E --> F

    style A fill:#fff3cd,stroke:#ffc107
    style B fill:#ffe6cc,stroke:#fd7e14
    style C fill:#d4edda,stroke:#28a745
    style D fill:#cce5ff,stroke:#4a90e2
    style E fill:#e2d9f3,stroke:#6f42c1
    style F fill:#d1ecf1,stroke:#17a2b8

Dies transformiert aufwandsarme, übergeordnete Absicht in umfassende technische Details.

4.2.2.2. Design-Muster und wiederverwendbare Bausteine#

Effektive Design-Systeme beruhen auf Musterbibliotheken.

Netzwerk-Design-Musterbibliothek

Jedes Muster codiert bewährte Architekturentscheidungen. Abweichungen erfordern explizite Genehmigung, aber ihre Bereitstellung sollte als normaler Betrieb angesehen werden.

4.2.2.3. Designs reproduzierbar machen#

Hier ist ein Problem: Man entwirft einen Standort am Montag und weist VLAN 100 zu. Man entwirft einen anderen Standort am Dienstag und weist VLAN 101 zu. Wenn man aber sechs Monate später die Montags-Entwürfe zur Validierung erneut ausführt, könnte das System VLAN 102 zuweisen, weil VLAN 100 vergeben ist.

Das ist nicht reproduzierbar. Die Lösung: Immer wenn eine Design-Anfrage gestellt wird, aufzeichnen, welches Design welche Ressourcen erhalten hat. Wenn dieselbe Anfrage erneut kommt, erhält man dasselbe VLAN. Das erfordert die permanente Verfolgung von Anfrage-zu-Ressource-Zuordnungen und die Zuteilung immer in derselben Reihenfolge.

• Deterministische Zuteilungsreihenfolge: Kandidaten immer in derselben Reihenfolge durchlaufen
• Atomare Zuteilung: Ressourcenreservierung ist atomar; partielle Zuteilung nicht möglich

Deshalb verwenden viele Design-Systeme inhaltadressierbaren Speicher (Hash des Designs) zur Sicherstellung der Konsistenz.

4.2.2.4. Unterschied zwischen Rendern und Erstellen#

Design-Systeme trennen zwei Phasen:

Rendern ohne Erstellen zu unterstützen ermöglicht:

• Sichere Validierung vor der Übernahme
• Was-wäre-wenn-Analysen ohne Risiko
• Team-Review- und Genehmigungsworkflows
• Staging in der Testumgebung zuerst

4.2.2.5. Design-Versionierung und Weiterentwicklung#

Netzwerk-Designs entwickeln sich über die Zeit weiter. Neue Muster entstehen. Tools verbessern sich. Designs von 2020 müssen möglicherweise für 2025 aktualisiert werden.

Herausforderungen bei der Design-Versionierung:

• Design Version 1 (2020): Zweigstellen-Vorlage: Einzelner Router, 2 VLANs

• Design Version 2 (2023): Zweigstellen-Vorlage: Dual-Router (Redundanz), 4 VLANs, verbesserte Sicherheit

Was passiert mit Zweigstellen, die mit Version 1 bereitgestellt wurden?

• Weiter mit alter Version laufen? (Sicherheitsschulden)
• Alle Zweigstellen zum Upgrade zwingen? (Änderungsrisiko)
• Schrittweise Migration? (Betriebskomplexität)

Lösungen:

Design-as-Code mit Versionierung

designs/
  ├─ branch_office_v1.yaml (veraltet 2023-01-01)
  ├─ branch_office_v2.yaml (aktuell)
  └─ branch_office_v2_beta.yaml (Test)

Sites:
  - site: DAL-01
    design: branch_office_v2 (referenziert spezifische Version)
    design_parameters: {...}

Dies ermöglicht:

• Genau zu wissen, welche Design-Version jeden Standort generiert hat
• Schrittweise Migration (Standort für Standort aktualisieren)
• Zurückrollen auf v1, wenn v2 Probleme hat
• Testen von v3 im Staging, bevor es ausgerollt wird

Sonderfall-Unterstützung

Die meisten Standorte verwenden die design_v2-Vorlage. Aber Standort DAL-01 hat besondere Anforderungen:

• Zusätzlicher Rack-Platz (Besonderheit des alten Gebäudes)
• Ungewöhnliche IP-Adressierung (Legacy-Zuteilung)
• Benutzerdefinierte Firewall-Regel (historische Geschäftsanforderung)

Lösung:

• design_v2 als Basis bereitstellen
• Standortspezifische Overrides anwenden
• Overrides separat verfolgen (den Sonderfall dokumentieren)

Das verhindert:

• Ausnahmen in die Vorlage einzudesignen (verunreinigt das Design)
• Manuelle Konfiguration von Ausnahmen (Drift über die Zeit)
• Verlust des Kontexts, warum Ausnahmen existieren

4.2.3. Konsumierung#

Daten, die in einer Datenbank eingeschlossen sind, sind nutzlos. Die Konsumierungsschicht ist das Mittel, durch das Menschen und Systeme tatsächlich an die Daten gelangen. Macht man es einfach, gewinnt man Akzeptanz. Macht man es schwierig, werden die Leute Umgehungslösungen finden.

4.2.3.1. API-Design und Sicherheit#

Verschiedene API-Stile dienen verschiedenen Konsumierungsmustern. Die folgenden gehören zu den beliebtesten:

API-Stilvergleich

Effektive Konsumierungsstrategien kombinieren oft mehrere Schnittstellen:

• REST für benutzerfreundliche, einfache Operationen
• GraphQL für komplexe Multi-Domain-Abfragen mit Autorisierungsfilterung
• gRPC/Streaming für hochvolumige Automatisierung
• Webhooks für reaktive nachgelagerte Systeme

Hinweis zu MCP (Model Context Protocol) Zusätzlich zu traditionellen API-Stilen ermöglichen aufkommende Interaktionsmodelle wie das Model Context Protocol (MCP) KI-Agenten, auf strukturierte, werkzeugorientierte Weise mit Systemen zu interagieren. Im Gegensatz zu REST oder gRPC, die Transport- und Anfragesemantiken definieren, konzentriert sich MCP auf sichere Fähigkeitserkennung, kontextuelle Datenabruf und kontrollierte Aktionsausführung für agentengesteuerte Workflows. Dieses Muster ist besonders relevant in KI-gestützten Betriebs- und Observability-Anwendungsfällen, wo automatisierte Reasoning-Systeme strukturierten Zugriff auf Telemetrie, Konfiguration und Abhilfewerkzeuge benötigen. Obwohl noch in der Entwicklung, stellt MCP einen Wandel von ressourcenzentrierten APIs hin zu agentorientierten Interaktionsmodellen dar.

Eine kritische Regel: Authentifizierung und Autorisierung auf der API-Ebene durchführen, nicht nachgelagert. Das verhindert Sicherheitslücken und sorgt dafür, dass Auditing korrekt funktioniert.

Mehr über Sicherheitsimplikationen in Kapitel 12.

4.2.3.2. API-Betrieb: Versionierung, Leistung und Caching#

Sobald APIs entworfen und gesichert sind, werden operative Aspekte rund um Weiterentwicklung und Leistung kritisch.

API-Versionierung und Evolution

Netzwerke sind langlebige Infrastruktur; Automatisierungssysteme müssen sich weiterentwickeln, ohne operative Workflows zu unterbrechen.

• URL-Versionierung: /api/v1/devices und /api/v2/devices behalten separate Implementierungen

  • Pro: Explizit, debuggbar, Clients wählen selbst den Zeitpunkt für ein Upgrade
  • Contra: Es werden mehrere Implementierungen gepflegt (was tatsächlich gut ist: es zwingt zur Migrationsplanung)

• Header-Versionierung: Gleicher Endpunkt, Version im Accept: application/vnd.company+json; version=2

  • Pro: Einzelner Endpunkt, sauberere URLs
  • Contra: In Logs unsichtbar, schwieriger zu debuggen, Clients machen dabei ständig Fehler

Auf jeden Fall sollten breaking Changes 6-12 Monate im Voraus über Deprecation-Header angekündigt werden:

Deprecation: true
Sunset: Mon, 01 Jan 2026 00:00:00 GMT
Link: <https://docs/migration>; rel="deprecation"

Ich empfehle URL-Versionierung: /api/v1/devices und /api/v2/devices. Ja, Header-Versionierung sieht in der Dokumentation sauberer aus. Aber wenn um 3 Uhr morgens etwas kaputtgeht und man Logs durchsucht, möchte man sofort /v1/ vs. /v2/ sehen, nicht durch Request-Header wühlen müssen, um herauszufinden, welche API-Version das Problem verursacht hat. Das zukünftige Bereitschafts-Ich wird es einem danken.

Leistung und Caching

Daten einzeln zu konsumieren kann für einige Anwendungsfälle gut funktionieren, aber wenn der Umfang wächst, werden Leistungsgrenzen irgendwann erreicht.

Massenoperationen ermöglichen die Aktualisierung von Tausenden von Objekten in einzelnen API-Aufrufen. Das ist für Skalierung unerlässlich, bringt aber Kompromisse mit sich:

• Einzelobjekt-API: POST /api/devices/device Vorteile: Jede Änderung wird validiert, klare Fehlermeldungen pro Objekt Kosten: 10.000 Geräte-Updates = 10.000 API-Anfragen + Roundtrips = Minuten

• Massen-API: POST /api/devices/bulk-update Vorteile: Einzelner Roundtrip für 10.000 Updates, Backend-Verarbeitung parallelisierbar Kosten: Validierungsabkürzungen (teure Prüfungen überspringen), schwieriger pro-Objekt-Fehler zu melden

Weitere Alternativen zur Verbesserung der Datenkonsumierung umfassen die Einschränkung des Umfangs durch:

• Paginierung und Filterung verhindern, dass Clients versehentlich Millionen von Objekten in den Speicher laden oder eine Zeitüberschreitung erleiden: GET /api/devices?location=datacenter-1&status=active&limit=100&offset=0

  Cursor-basierte Paginierung bietet Vorteile gegenüber offset-basierter Paginierung bei großen Datensätzen, da sie für verteilte Systeme effizienter ist und auch dann konsistent bleibt, wenn Daten zwischen Anfragen geändert werden.

• Caching-Strategien verbessern die Leistung erheblich:

  • Serverseitiges Caching: Redis-Cache von “alle Geräte an Standort X”, der ungültig wird, wenn sich ein Gerät an diesem Standort ändert
  • Clientseitiges Caching: HTTP-ETags ermöglichen Clients die Validierung zwischengespeicherter Daten ohne erneutes Abrufen
  • Validierungsebenen-Bypass: Für schreibgeschützte Abfragen Validierungsprüfungen überspringen

• Rate-Limiting schützt Backends vor Überlastung. Zum Beispiel:

  • 10 Anfragen/Sekunde pro Benutzer
  • 1.000 Anfragen/Minute pro API-Schlüssel
  • Rückdrucksignale (HTTP 429) teilen Clients mit, langsamer zu werden

4.2.3.3. Kontextbewusstes Datenmodellierung#

Verschiedene Menschen brauchen verschiedene Dinge. Netzwerkingenieure wollen Daten suchen und finden, bestimmte Felder mit Validierungsfeedback bearbeiten und Beziehungen sehen. Automatisierungs-Workflows brauchen APIs, Transaktionen und Webhooks. Betriebsteams wollen aufgabenorientierte Ansichten und Audit-Trails. Das Unternehmen möchte Berichte ohne technische Details. Externe Systeme müssen Daten in beide Richtungen synchronisieren.

Beachten Sie, dass die Benutzeroberfläche des Konsumierungsblocks zur Präsentationsschicht gehört. Mehr dazu behandeln wir in Kapitel 8.

Die Daten müssen sich an den jeweiligen Konsumierungskontext anpassen. Beispielsweise müssen nicht alle Gerätedetails für jede Persona zugänglich sein. Kontextbewusste Anpassung macht die Datenkonsumierung effizienter und effektiver.

Ein Netzwerkingenieur benötigt Schnittstellen- und Routing-Details. Finanzen möchten Kosten- und Garantieinformationen. Sicherheit möchte die Compliance-Zone. Anstatt allen 500 Felder zurückzugeben, erhält jeder Verbraucher nur das, was er braucht. Dies kann mit API-Abfrageparametern (?view=network_engineer) oder GraphQL erreicht werden, indem Clients spezifische Felder anfordern können.

Die Herausforderung: Ein Datenmodell passt nicht für alle Verbraucher

Stellen Sie sich ein einzelnes Geräteobjekt im SoT vor, das Hunderte von Attributen enthält:

• Hardware-Details (Modell, Seriennummer, Firmware-Version)
• Netzwerkkonfiguration (IP-Adressen, VLANs, Routing-Protokolle)
• Betriebsmetadaten (Standort, Kostenstelle, Garantieablauf)
• Servicebeziehungen (welche Kunden dieses Gerät nutzen)
• Sicherheitskontext (Compliance-Zone, Zugriffsrichtlinien)

Verschiedene Verbraucher benötigen grundlegend verschiedene Ansichten dieser Daten:

Beispiel: Gerät “router-core-01” in verschiedenen Kontexten

Implementierungsmuster

1. Ansichtsbasierte Transformationen: API-Abfragen geben den gewünschten Kontext an, der Server transformiert das Datenmodell entsprechend

   GET /api/devices/router-core-01?view=network-engineer
   → Gibt zurück: {interfaces: [...], bgp_peers: [...], vlans: [...]}
   
   GET /api/devices/router-core-01?view=finance
   → Gibt zurück: {cost_center: "...", warranty_expiry: "...", purchase_cost: ...}

2. GraphQL-Feldauswahl: Verbraucher fordern explizit nur benötigte Felder an

   query NetworkEngineerView {
     device(name: "router-core-01") {
       interfaces { name, ip_address, status }
       bgp_neighbors { peer_ip, state }
     }
   }
   
   query FinanceView {
     device(name: "router-core-01") {
       cost_center
       purchase_date
       warranty_expiration
     }
   }

3. Projektionsschichten: Backend berechnet abgeleitete Ansichten, die für spezifische Zugriffsmuster optimiert sind

   • Netzwerktopologie-Graph: Geräte als Knoten, Verbindungen als Kanten (für Topologievisualisierung)
   • Service-Abhängigkeitsbaum: Hierarchische Ansicht von Diensten → Geräten → Komponenten (für Wirkungsanalyse)
   • Compliance-Matrix: Geräte gruppiert nach Zone mit Richtlinien-Compliance-Status (für Auditing)

4. Domänenspezifische Sprachen (DSLs): Spezialisierte Abfragesprachen, die auf das mentale Modell des Benutzers zugeschnitten sind

   • Netzwerkingenieur: “Zeige mir alle Geräte mit ausgefallener BGP-Sitzung in datacenter-1”
   • Finanzen: “Berechne die monatliche Abschreibung für im Q3 2025 erworbene Geräte”
   • Sicherheit: “Liste Geräte in der PCI-Zone mit kritischen CVEs auf”

Vorteile der kontextbewussten Modellierung

Es müssen jedoch Herausforderungen und andere Überlegungen berücksichtigt werden:

• Pflegeaufwand für Ansichten: Jede neue Ansicht erfordert Definition, Tests, Dokumentation
• Konsistenz über Ansichten hinweg: Dieselben Daten, die durch mehrere Ansichten zugänglich gemacht werden, müssen konsistent bleiben
• Leistungskomplexität: Die Berechnung dynamischer Ansichten erhöht die Latenz; erfordert Caching-Strategien
• Auffindbarkeit: Verbraucher müssen wissen, welche Ansichten existieren und wann sie verwendet werden sollen

Kontextbewusste Modellierung ist die Brücke zwischen Datenstrukturoptimierung (wie wir Daten effizient speichern) und Konsumierungsoptimierung (wie Verbraucher natürlich auf Daten zugreifen). Sie erkennt an, dass der Source of Truth viele Herren bedient, von denen jeder seine eigene Perspektive hat, was “Wahrheit” für seine Arbeit bedeutet.

4.2.3.4. KI-gestützte Schnittstellen#

Der Einsatz von KI auf der Konsumierungsschicht reduziert den kognitiven Aufwand bei der Arbeit mit großen, komplexen Datenmodellen. Drei Muster kommen in modernen SoT-Implementierungen zunehmend vor:

• Kontextuelle Vorschläge: Während man einen Gerätenamen eintippt, schlägt das System passende Geräte vor, die man zuvor an diesem Standort bearbeitet hat. Beim Erstellen eines Dienstes schlägt es vernünftige technische Parameter basierend auf dem Servicetyp und historischen Mustern vor. Dies reduziert Eingabefehler ohne zusätzliche Validierungsreibung.

• Anomaliewarnungen beim Schreiben: Vor einem Massen-Update meldet die Schnittstelle, wenn die Operation im Vergleich zu historischen Mustern ungewöhnlich ist. Eine Massen-VLAN-Neuzuweisung, die normalerweise 10 Geräte betrifft, aber dabei 400 Geräte berühren soll, löst einen Bestätigungsschritt aus. Das System blockiert die Operation nicht; es stellt eine Frage.

• Natürlichsprachliche Abfragen: LLM-gestützte Schnittstellen ermöglichen es Betreibern, den SoT in einfacher Sprache zu befragen: “Welche Geräte in Gebäude B haben keinen Monitoring-Tag?” Die Schnittstelle übersetzt dies in eine strukturierte API-Abfrage und gibt Ergebnisse in einer für Menschen lesbaren Form zurück. Dies ist für Ad-hoc-Untersuchungen wertvoll, ersetzt aber keine strukturierten Automatisierungsschnittstellen.

Alle drei Muster basieren auf demselben Fundament: Zugang zu historischen Betriebsdaten und einem gut modellierten Schema, über das die KI schlussfolgern kann. Abschnitt 4.2.4.4 behandelt, wie ähnliche Techniken auf die Datenqualitätsvalidierung beim Schreiben angewendet werden.

4.2.4. Durchsetzung#

Schlechte Daten zerstören die Automatisierung. Falsche Absicht führt zu kaputten Netzwerken, Sicherheitsverletzungen und verwirrten Betriebsteams. Durchsetzung ist der Wächter: Sie stoppt offensichtlich falsche Daten beim Eingang und erklärt klar, warum.

4.2.4.1. Schema- und Einschränkungsdurchsetzung#

Es gibt viele Möglichkeiten, Schema-Validierung zu implementieren, von generischen Programmiersprachen bis hin zu spezifischeren Lösungen:

• JSON Schema: JSON-Dokument, das Dateneinschränkungen beschreibt, um sie mit tatsächlichen Daten zu vergleichen.
• CUE: Bietet typisierte, validierte Datengenerierung mit Einschränkungen und Validierung.
• YANG: Netzwerkspezifische Modellierungssprache mit integrierter Einschränkungsdurchsetzung.

Zum Beispiel können mit JSON Schema JSON- (oder YAML-)Daten validiert werden:

• JSON-Daten

{
  "hostname": "sw-core-01",
  "mgmt_ip": "192.0.2.10",
  "role": "core",
  "interfaces": [
    {
      "name": "Ethernet1",
      "enabled": true,
      "vlan": 100
    },
    {
      "name": "Ethernet2",
      "enabled": false,
      "vlan": 200
    }
  ]
}

• JSON Schema

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["hostname", "mgmt_ip", "role", "interfaces"],
  "additionalProperties": false,
  "properties": {
    "hostname": {
      "type": "string",
      "pattern": "^[a-z0-9-]+$"
    },
    "mgmt_ip": {
      "type": "string",
      "format": "ipv4"
    },
    "role": {
      "type": "string",
      "enum": ["core", "distribution", "access"]
    },
    "interfaces": {
      "type": "array",
      "minItems": 1,
      "items": {
        "type": "object",
        "required": ["name", "enabled", "vlan"],
        "additionalProperties": false,
        "properties": {
          "name": {
            "type": "string",
            "pattern": "^Ethernet[0-9]+$"
          },
          "enabled": {
            "type": "boolean"
          },
          "vlan": {
            "type": "integer",
            "minimum": 1,
            "maximum": 4094
          }
        }
      }
    }
  }
}

4.2.4.2. Harte vs. weiche Durchsetzung#

Schlechte Daten ablehnen. Harter Stopp. Ich habe zu viele “Soft-Validation”-Systeme gesehen, die zu Datenmüllhalden wurden, weil “nur dieses eine Mal” zur Standardpraxis wurde. Wenn etwas wichtig genug zu validieren ist, ist es wichtig genug zu erzwingen.

Aber wie immer gibt es Ausnahmen:

1. Richtlinienempfehlungen (keine Regeln): “Sie verwenden ein /22-Subnetz, obwohl wir normalerweise /24 verwenden” ist eine Warnung, kein Fehler. Den Benutzer warnen, protokollieren, aber fortfahren lassen, wenn er es überschreibt.

2. Teure objektübergreifende Prüfungen: Wenn die Validierung mehr als einige Sekunden dauert, die Änderung akzeptieren und asynchron validieren. Aber das Ergebnis trotzdem durchsetzen: die Verletzung kennzeichnen, den Benutzer benachrichtigen und Korrekturen verlangen.

3. Brownfield-Netzwerkerkennung: Beim Import bestehender Konfigurationen werden überall Verletzungen gefunden. Diese markieren, aber den Import nicht blockieren. Der gesamte Zweck besteht darin, zu entdecken, was tatsächlich vorhanden ist, auch wenn es gegen das ideale Modell verstößt.

Alles andere? Ablehnen. Die Automatisierung ist auf vertrauenswürdige Daten angewiesen. Schlechte Daten bedeuten Ausfälle.

4.2.4.3. Validierungskosten und Leistungskompromisse#

Validierung ist nicht kostenlos. Eine Hierarchie von Validierungskosten beeinflusst Designentscheidungen:

graph LR
    SPEED["⚡ GESCHWINDIGKEIT"]
    V1["< 1ms<br/>Typvalidierung"]
    V2["~10ms<br/>Eindeutigkeit"]
    V3["5-50ms<br/>Regex"]
    V4["50-200ms<br/>Referentielle<br/>Integrität"]
    V5["100-500ms<br/>Regelengine"]
    V6["1-5 Sek.<br/>Externe API"]
    V7["Stunden+<br/>Konsistenz"]
    THOROUGH["GRÜNDLICHKEIT 🎯"]
    
    SPEED --> V1
    V1 --> V2
    V2 --> V3
    V3 --> V4
    V4 --> V5
    V5 --> V6
    V6 --> V7
    V7 --> THOROUGH
    
    style SPEED fill:none,stroke:none,font-size:14px,font-weight:bold
    style THOROUGH fill:none,stroke:none,font-size:14px,font-weight:bold
    style V1 fill:#d4edda,stroke:#28a745,stroke-width:2px
    style V2 fill:#d7ecf1,stroke:#17a2b8,stroke-width:2px
    style V3 fill:#dfe8f1,stroke:#17a2b8,stroke-width:2px
    style V4 fill:#fff3cd,stroke:#ffc107,stroke-width:2px
    style V5 fill:#ffe8cd,stroke:#ffc107,stroke-width:2px
    style V6 fill:#f8d7da,stroke:#dc3545,stroke-width:2px
    style V7 fill:#f5c2c7,stroke:#dc3545,stroke-width:2px

Praktische Systeme wählen ein Leistungsziel und validieren für synchrone Schreibpfade nur bis zu diesem Niveau:

• Schneller Pfad (< 10ms): Typ-, Regex-, lokale Index-Prüfungen
• Standardpfad (< 100ms): Eindeutigkeit, referentielle Integrität
• Langsamer Pfad (< 5 Sek.): Regelengine, komplexe Geschäftslogik
• Asynchroner Pfad (Stunden später): Hintergrundvalidierung, Konsistenzprüfungen

4.2.4.4. KI-gestützte Datenqualität#

Machine Learning verbessert die Datenqualität ohne Durchsatzverlust. Diese KI-gesteuerten Validierungstechniken ergänzen die benutzerseitigen KI-Funktionen in Abschnitt 4.2.3.4 und schaffen eine umfassende intelligente Datenschicht.

Anomalieerkennung

Historische Muster gegen neue Anfragen abgleichen, um Inkonsistenzen zu erkennen:

• Historisches Muster: Beim Einrichten einer neuen Zweigstelle erstellen Betreiber VLANs im Bereich 1000-1999, weisen sie site_a zu und konfigurieren statisches Routing
• Neue Anfrage: VLAN 2500 erstellen, site_c zuweisen, OSPF aktivieren
• Warnung: “Dieses VLAN-Erstellungsmuster ist ungewöhnlich. Sind Sie sicher? (98% Konfidenz, dass es im Bereich 1000-1999 liegen sollte)”
• ML-Technik: Clustering und Ausreißererkennung auf historischen Änderungsvektoren

Korrekturvorschläge

Automatisch Korrekturen zur wahrscheinlichsten gültigen Lösung vorschlagen:

• Eingabe: IP-Adresse “192.0.2.1/33” (ungültige Präfixlänge > 32)
• System: “Meinten Sie /24? (abgeleitet aus ähnlichen Subnetzen an diesem Standort)”
• ML-Technik: Mustererkennung bei Subnetz-Zuweisungen innerhalb desselben Standorts

Vektor-Embeddings für Konsistenz

Embeddings verwenden, um signifikante Abweichungen von Peer-Konfigurationen zu erkennen:

• Embeddings jeder Gerätekonfiguration speichern
• Neue Gerätekonfiguration einreichen
• Embedding mit ähnlichen Geräten in derselben Rolle vergleichen
• Bei signifikantem Unterschied: “Dieses Gerät weicht von Peers in der Rolle ab: Ähnliche Geräte haben NTP-Server X,Y,Z und Syslog an Server Z”
• ML-Technik: Kosinus-Ähnlichkeit auf Gerätekonfigurations-Embeddings

Überlegungen zur ML-Implementierung

Beachten Sie die Verwendung von “Konfidenz”-Werten. Dies ist ein wichtiges Konzept bei der Verwendung von KI, da es mehr Kontext darüber gibt, wie sehr man sich auf die Empfehlung verlassen kann. Paaren Sie KI-Vorschläge immer mit Erklärungen des zugrunde liegenden Musters, das sie ausgelöst hat.

4.2.4.5. Kosten der Durchsetzung: Systemdesign-Implikationen#

Hochwertige Validierung beeinflusst die Architektur:

4.2.5. Versionierung#

Die Netzwerkabsicht ändert sich ständig. Geräte werden hinzugefügt, Konfigurationen aktualisiert, Dienste verschoben, Richtlinien angepasst. Versionierung ermöglicht es zu verstehen, was wann wahr war, wie es dazu kam und wie man bei Bedarf zu etwas Sicherem zurückkehren kann.

4.2.5.1. Versionskontrolle und unveränderliche Audit-Trails#

Alle Änderungen müssen unveränderlich aufgezeichnet werden, um eine vollständige Historie zu erstellen. Dies kann verschiedene Formen annehmen, zum Beispiel:

• Änderungsprotokolle

  Change Event:
    timestamp: 2025-02-07T14:32:15Z
    user: engineer@company.com
    action: UPDATE
    resource_type: vlan
    resource_id: vlan-100
    changes:
      description: "Customer VLAN" → "Production Customer VLAN"
      assigned_sites: [site-a, site-b] → [site-a, site-b, site-c]
    reason: "Adding new office location"
    request_id: req-12345

• Git Commits

  commit 0c0ad51152f9b3be307802badb15eca8d121c576 (HEAD -> new-site, origin/new-site)
  Author: Engineer <engineer@company.com>
  Date:   Sat Feb 7 09:43:59 2026 +0100
  
      Adding a new site: BCN01
  
  diff --git a/sites.yaml b/site.yaml
  index ae18c87..dabf6c5 100644
  --- a/sites.yaml
  +++ b/sites.yaml
  @@ -219,51 +219,1279 @@ sites:
  
  + BCN01:

Dieses unveränderliche Protokoll beantwortet kritische Fragen:

• Was war die Netzwerkabsicht an Datum X? (Zeitreise)
• Wer hat diese Änderung vorgenommen und warum? (Rechenschaftspflicht)
• Welche Bereitstellungskonfiguration entspricht dieser Absicht? (Rückverfolgbarkeit)
• Was hat sich zwischen den Versionen Y und Z geändert? (Diff/Vergleich)

Unveränderlichkeit ist der Schlüssel: Niemand, nicht einmal Administratoren, kann historische Aufzeichnungen bearbeiten. Das verhindert Vertuschungen und stellt sicher, dass Audit-Trails vertrauenswürdig bleiben.

Versionierung ist auch mit Aufbewahrungsrichtlinien verbunden und erfordert eine Balance zwischen Compliance und Praktikabilität, zum Beispiel:

• Alle Änderungen 7 Jahre aufbewahren (gesetzliche Anforderung)
• Zwischenversionen nach 2 Jahren bereinigen (z.B. wenn VLAN 100 sich 10 Mal geändert hat, nur Anfang und Ende behalten)
• Nach 1 Jahr in Cold Storage archivieren (aus Kostengründen)

In Bezug auf Datenänderungsereignisse sind Event-Sourcing-Muster (alle Änderungen als Ereignisse speichern zur vollständigen Datenrekonstruktion) leistungsfähig, aber bei der Verwaltung von Netzwerkinfrastruktur weniger verbreitet. Dies liegt daran, dass Netzwerkabsicht hochgradig zustandsbehaftet ist. Die aktuellen Daten sind wichtiger als die Abfolge der Änderungen, die dazu geführt hat. Außerdem umfassen Netzwerkänderungen oft externen Zustand (Gerätekonfigurationen, IP-Zuweisungen in externen Systemen), der allein aus Ereignissen nicht vollständig rekonstruiert werden kann. Event-Sourcing kann jedoch für spezifische Anwendungsfälle wie Audit-Compliance oder forensische Analysen wertvoll sein.

4.2.5.2. Versionskontrollmuster: Branching, Merging und Rollback#

Moderne Source-of-Truth-Systeme übernehmen stark aus Softwareversionskontrollmustern. Diese Fähigkeiten ermöglichen sichere parallele Arbeit, experimentelle Änderungen und schnelle Wiederherstellung nach Fehlern.

Branching für parallele Arbeitsströme

Jede Organisation mit mehr als einem Ingenieur oder KI-Agenten, die parallel arbeiten, braucht eine Möglichkeit zu arbeiten, ohne andere zu blockieren. Wenn ein Akteur (Mensch oder KI) an der Bereitstellung neuer Daten arbeitet, kann er den gesamten Source of Truth nicht blockieren.

Aus der Softwareentwicklung lernend ermöglichen Branching-Mechanismen (Verzweigungsmechanismen) parallele Arbeitsströme. Jedes Team kann an parallelen Datenpfaden arbeiten und diese schließlich mit dem “Haupt”-Pfad zusammenführen, wenn sie bereit sind. Diese Zusammenführung ist eine Gelegenheit, eventuell eingeführte Inkonsistenzen zu beheben.

Beispiel-Workflow:

main branch (production intent)
  │
  ├─── feature/add-dallas-office (Engineer A)
  │     • Creates site DAL-01
  │     • Allocates VLANs 2100-2110
  │     • Defines 5 new devices
  │
  └─── feature/upgrade-ntp-servers (Engineer B)
        • Changes NTP config for all devices
        • Updates 3,000 device records

Wenn beide Branches wieder mit main zusammengeführt werden:

• Kein Konflikt: Verschiedene Objekte geändert → automatisches Merge
• Konflikt erkannt: Beide haben NTP von device-core-01 geändert → manuelle Auflösung erforderlich
• Validierung: Das zusammengeführte Ergebnis muss alle Durchsetzungsregeln bestehen, bevor ein Commit möglich ist

Die Implementierung dieses Branching-Mechanismus in traditionellen Datenbanken ist ein wichtiges Problem für sich. Zum Beispiel haben NetBox und Nautobot, die relationale Datenbanken nutzen, verschiedene Ansätze gewählt: NetBox verwendet Datenbankkopien für das Branching, während Nautobot Dolt nutzt (eine SQL-Datenbank mit integrierter Git-ähnlicher Versioning). Infrahub, von Grund auf mit Git-ähnlichem Branching entworfen, hat dies mithilfe einer Graph-Datenbank mit nativen Branching-Fähigkeiten umgesetzt.

Rollback und Wiederherstellung

Fehler passieren. Daten-Rollback muss schnell und zuverlässig sein. Beachten Sie, dass es sich um den Rollback der Absichtsdaten selbst handelt, nicht direkt um die Netzwerkkonfiguration.

Das Zurücksetzen von Daten erfordert, dass die Ausführungskomponente die Konfigurationsänderungen durchsetzt (Konfigurationen auf der Netzwerkinfrastruktur können zurückgesetzt werden, wenn verfügbar, aber letztendlich müssen sowohl das Netzwerk als auch die Absicht synchronisiert werden, um einen stabilen Zustand zu erhalten).

Zur Unterstützung des Daten-Rollback gibt es zwei Hauptansätze:

Rollback kann auf zwei Arten ausgelöst werden:

• Manuell: Betreiber erkennt Problem, initiiert Rollback
• Automatisiert:
  • Observability erkennt erhöhte Fehlerraten nach der Bereitstellung
  • Validierung nach der Bereitstellung schlägt fehl (“500 Geräte nach Änderung nicht erreichbar”)
  • Schwellenwert für Geschäftsauswirkungen überschritten (“Kunden-SLA-Verletzungen > 10”)

Die Kombination von Branching (parallele Arbeit ohne Konflikte) und Rollback (schnelle Wiederherstellung nach Fehlern) bietet die zeitliche Flexibilität, die die groß angelegte Netzwerkautomatisierung erfordert.

4.2.5.3. Atomare Transaktionen und Konsistenzgarantien#

Transaktionsgarantien stellen die Datenkonsistenz sicher, wenn mehrere zusammengehörige Änderungen zusammen erfolgreich sein oder scheitern müssen:

• Atomarität: Entweder alles gelingt oder alles wird zurückgesetzt
• Konsistenz: Dateneinschränkungen vor und nach dem Commit eingehalten
• Isolation: Gleichzeitige Transaktionen stören sich nicht
• Dauerhaftigkeit: Nach dem Commit bleibt es bestehen, auch wenn das System abstürzt

Dies zu implementieren erfordert sorgfältiges Design:

• Datenbanktransaktionen (wenn alle Daten in einer einzelnen DB sind)
• Verteilte Transaktionen (wenn Daten über Systeme verteilt sind)
• Saga-Muster (wenn keine native Unterstützung für verteilte Transaktionen)

In Kapitel 11 werden wir mehr darüber behandeln, wie sich diese Anforderungen auf zuverlässige Systeme auswirken.

4.2.5.4. Änderungsgenehmigungsworkflows#

Sobald Datenänderungen vorgeschlagen werden, können sie menschliche Genehmigungsworkflows erfordern, bevor sie aktiv werden. Daten durchlaufen typischerweise mehrere Phasen, bevor sie als endgültig betrachtet werden, ähnlich wie Continuous-Integration-Pipelines.

graph LR
    A["📝 Betreiber schlägt Änderung vor<br/>50 neue Zweigstellengeräte hinzufügen"] --> C["📦 STAGING<br/>Noch kein Netzwerkeffekt<br/>Vorschau, Test, Dry-Run"]
    C --> D["✓ Automatisierte Prüfungen Validierung<br/>Schema & Einschränkungen?"]
    C --> E["✓ Simulation<br/>Routing/MPLS-Auswirkung?"]
    C --> F["✓ Compliance<br/>Sicherheitsrichtlinien?"]
    D --> G{Alle Prüfungen<br/>bestanden?}
    E --> G
    F --> G
    G -->|Ja| H["👥 Menschliche Überprüfung<br/>Change Control"]
    G -->|Nein| I["❌ Abgelehnt<br/>Antragsteller benachrichtigen"]
    H --> J{Genehmigt?}
    J -->|Ja| K["✅ GENEHMIGT<br/>Bereit zur Bereitstellung"]
    J -->|Nein| I

Ein Beispiel für einen Datenänderungs-Workflow könnte so aussehen:

1. Betreiber schlägt Änderung vor: “50 neue Zweigstellengeräte hinzufügen”

2. Änderung gelangt in STAGING: (noch kein Netzwerkeffekt, kann in der Vorschau angezeigt, getestet, als Dry-Run ausgeführt werden)

3. Automatisierte Prüfungen laufen (Continuous Integration):

   • Validierung: Besteht es Schema und Einschränkungen?
   • Simulation: Bricht es Routing, MPLS usw.?
   • Compliance: Verletzt es Sicherheitsrichtlinien?
   • Bericht: ✓ Alle bestanden

4. Menschliche Überprüfung:

   • Change-Control-Komitee erhält Benachrichtigung
   • Überprüft Diff, Begründung, Auswirkungsradius
   • Genehmigt oder fordert Änderungen an

5. Genehmigungsentscheidung, Änderung in GENEHMIGT-Zustand.

6. Bereitstellungsauslösung: Nach der Genehmigung löst es den Workflow-Komponenten aus, um die damit verbundenen Änderungen letztendlich im Netzwerk zu deployen (ein häufiger Auslöser für automatisierte Ausführungs-Workflows)

Allerdings erfordern nicht alle Änderungen menschliche Genehmigung, und hier machen die meisten Organisationen einen Fehler. Change Control Boards sind der Ort, wo Automatisierung stirbt. Ich sage nicht, Genehmigungen zu überspringen, ich sage, sie zu automatisieren (d.h. Änderungsgenehmigung in großem Maßstab).

Wenn Ihr CAB wöchentlich tagt, um das Hinzufügen von VLANs zu genehmigen, haben Sie bereits verloren. Leitplanken einbauen, die 95% der Änderungen automatisch genehmigen, und menschliche Überprüfung für die tatsächlich riskanten Dinge aufsparen. Beim Einrichten einer AWS-VPC warten Betreiber beispielsweise nicht auf menschliche Genehmigung für die Netzwerkänderung: Sie folgen bewährten Vorlagen innerhalb definierter Grenzen.

Die Regel lautet: Änderungen, die klar definierten Leitplanken entsprechen, laufen automatisch durch; nur die Leitplankenlogik selbst erfordert menschliche Überprüfung und Genehmigung. Minimale Leitplankenabdeckung und maximale Auswirkungstoleranz definieren. Dann aus dem Weg gehen und das System arbeiten lassen.

Andernfalls ist die “Automatisierung” nur eine schönere Art, auf Meetings zu warten.

4.2.6. Aggregation#

Die Netzwerkdaten leben nicht in einem Vakuum. HR-Systeme verfolgen, wer wo arbeitet. Asset-Management kennt Gerätedetails und Garantiedaten. IPAM-Systeme besitzen IP-Adresszuweisungen. Circuit-Anbieter haben Konnektivitätsinformationen. Services-Teams haben SLA-Details.

Kein weiteres Datensilo aufbauen. Die Organisation hat bereits zu viele. Wenn der Source of Truth nicht aus ServiceNow, Infoblox und dem CMDB beziehen kann, wird nur Spreadsheet 2.0 mit einer API gebaut. Niemand wird es pflegen. Man verbringt sein Leben damit, Leute zu bitten, “bitte den SoT zu aktualisieren”, während sie ignoriert werden und ihre bestehenden Tools weiter nutzen.

Aggregation ist nicht optional: Daten aus bestehenden Systemen einbeziehen, in beide Richtungen synchronisiert halten und eine einheitliche Ansicht präsentieren. Der Source of Truth sollte eine Federationsschicht sein, keine Ersatzdatenbank.

4.2.6.1. Man beginnt nicht bei Null#

Mit ziemlicher Sicherheit sind Daten über mehrere Systeme verteilt. Jedes System ist für seine Domäne maßgeblich: HR besitzt die Organisation, Asset-Systeme besitzen Hardware-Details, IPAM besitzt IP-Zuweisungen. Der Source of Truth ersetzt diese Systeme nicht; er bündelt ihre Daten in einer konsistenten Schnittstelle, damit Clients nicht fünf verschiedene Systeme abfragen müssen.

• Organisatorischer Kontext:

  • HR-System: Abteilungen, Teams, Rollen, Verantwortungsmatrix

• Infrastruktur:

  • Asset-Management: Hardware-Details, Seriennummern, Beschaffung, Garantie
  • Cloud-Plattform: VPCs, Subnetze, Sicherheitsgruppen, Instanzdetails
  • Circuit-Anbieter (extern): Konnektivitätsstatus, Auslastung, Störungen
  • IPAM-System: IP-Zuweisungen, DHCP-Bereiche, DNS-Einträge
  • Konfigurationsmanagement: Vorlagen, Baselines

• Dienste:

  • Service-Katalog: Servicedefinitionen, SLAs, Kunden
  • Billing-System: Rückverrechnungen, Kapazitätsplanung

Jedes System ist innerhalb seiner Domäne maßgeblich (Domäne als Datentyp oder klar abgegrenzter Teilbereich des Datentyps verstanden). Der Source of Truth ersetzt sie nicht; er orchestriert ihre Daten zu einem kohärenten Ganzen, das über eine konsistente Schnittstelle zugänglich ist, ohne dass komplexe Client-Anwendungen Daten aus mehreren Quellen korrelieren müssen.

4.2.6.2. Konfliktlösung in föderierten Systemen#

Wenn Daten aus mehreren Quellen kommen, entstehen Konflikte:

• Zentrales IPAM-System sagt: 192.0.2.0/24 ist Kunde X zugewiesen
• Das CMDB sagt: 192.0.2.0/24 ist Kunde Y zugewiesen

Wer hat Recht? Es hängt von der Autoritätszuweisung durch Governance ab.

Eine Strategie zur Ressourcen-Domänen-Eigentümerschaft könnte beispielsweise festlegen:

• Zentrales IPAM, Source of Truth für:

  • IP-Adresszuweisungen
  • Subnetzgrößen
  • DHCP-Bereiche

• CMDB, Source of Truth für:

  • VLAN-zu-Subnetz-Mappings
  • Interface-IP-Zuweisungen
  • Betriebsstatus der Netzwerkschnittstelle

Strategien zur Konfliktlösung umfassen:

• Quellenautorität (am häufigsten): Eine Governance-Entscheidung bezeichnet ein System als maßgeblich (z.B. ist das Asset-System maßgeblich für Gerätezugangsdaten)

• Zeitstempelbasiert: Letzten Änderungszeitstempel verwenden; die aktuellste Änderung gewinnt. Risiko: Berücksichtigt keine Korrekturänderungen vs. Fehler

• Logische Auflösung: Kontext auswerten:

  • SoT-Wert wird aktuell auf Geräten verwendet (aktuell, nachweislich funktionierend)
  • Asset-System-Wert wird als Desired State (Soll-Zustand) beansprucht
  • Option 1: Aktuellem vertrauen (was funktioniert)
  • Option 2: Soll-Zustand vertrauen (Governance-Modell)
  • Option 3: Erkennen: Konfiguration auf Gerät stimmt mit keinem der Werte überein, weiter untersuchen

• Manuelle Eskalation: Wenn das Vertrauen mittel ist (Werte unterscheiden sich, sind aber nicht widersprüchlich), zur menschlichen Überprüfung eskalieren

4.2.6.3. Aggregationsarchitektur#

Es gibt zwei grundlegende Ansätze zur Datenaggregation:

4.2.6.4. Synchronisierungsmechanismen#

Die Datenkonsistenz über Systeme hinweg zu erhalten ist die Kernherausforderung der Aggregation. Die Wahl der Architektur bestimmt, welchen Synchronisierungsansatz man verwendet:

Es gibt kein Echtzeit-Synchronisierungssystem. Daten werden schließlich konsistent, aber das kann einige Zeit dauern, die für jeden Anwendungsfall evaluiert werden muss.

4.2.6.5. Daten-Governance und Autoritätsrahmen#

Effektive Federation erfordert klare Governance mit expliziten Definitionen pro Datendomäne. Zum Beispiel:

Für jedes Datenelement sollten Autoritätsmetadaten verfolgt werden:

• Quellsystem: Woher stammt es?
• Letzte Synchronisierungszeit: Wann wurde es zuletzt verifiziert?
• Aktualisierungsmethode: Poll, Push oder Webhook?
• Autoritätsstufe: Wie vertrauenswürdig sind diese Daten?

Mit diesen Metadaten kann das System fundierte Governance-Entscheidungen über den Umgang mit Daten treffen.

Und wenn man mit mehreren Einheiten spielt, muss man auf Ausfälle vorbereitet sein. Externe Systeme werden unweigerlich ausfallen. Wenn eine föderierte Quelle nicht verfügbar ist (z.B. IPAM 30 Minuten ausgefallen), gibt es mehrere Strategien (jede hat ihre Nachteile):

1. Operationen blockieren: “Ohne IPAM können keine IP-Adressen zugewiesen werden”
2. Gecachte Daten verwenden und als veraltet markieren: “Gecachte IPAM-Daten von vor 2 Stunden werden verwendet; dies kann inkonsistent sein”
3. Graceful Degradation: “Geräte können noch bereitgestellt werden, IP-Zuweisung überspringen und in die Warteschlange stellen, bis IPAM wiederhergestellt ist”

4.2.7. Brownfield-Einführung#

Die sechs oben beschriebenen Funktionalitäten beschreiben, wie ein SoT funktioniert, sobald er befüllt und vertrauenswürdig ist. Zwei operative Realitäten bestimmen, ob er dorthin gelangt und dort bleibt: wie man ihn aus einem bestehenden Netzwerk befüllt und wie man ihn im Laufe der Zeit genau hält. Keines davon passt sauber zu einer einzigen Funktionalität, aber beide sind Voraussetzungen dafür, dass eine der sechs in der Praxis funktioniert.

Wenn ein Source of Truth in einem bestehenden Netzwerk eingesetzt wird, steht man vor einem kniffligen Problem: Wie befüllt man ihn mit dem aktuellen Zustand, ohne einfach den gesamten Legacy-Ballast als permanente Wahrheit einzubetten?

Der falsche Ansatz: Geräte abfragen und annehmen, “was läuft = was sein soll”. Damit werden alle Workarounds, Hacks und technischen Schulden direkt in den Source of Truth geladen.

Der richtige Ansatz: Den aktuellen Netzwerkzustand als Ausgangspunkt nutzen, nicht als Wahrheit. Einen Snapshot erstellen, ihn einladen, dann bewusst neu gestalten, um es sauber zu machen. Sobald man das Design hat, das man tatsächlich will, aufhören, aus dem Netzwerk zu synchronisieren. Der Source of Truth wird zum Chef; das Netzwerk folgt seiner Führung.

So sieht das in der Praxis aus:

1. Bootstrap: Einen Snapshot des aktuellen Netzwerks erstellen (Geräte, IPs, VLANs, Circuits) und ihn als Ausgangsdaten in den Source of Truth laden.

2. Neu gestalten: Über Wochen und Monate lassen die Leute diese Daten überprüfen und entscheiden, was der beabsichtigte Zustand tatsächlich sein soll. Wahrscheinlich werden redundante VLANs konsolidiert, Legacy-Zeug bereinigt, Namensgebung standardisiert und Designvorlagen für zukünftige Bereitstellungen geschrieben.

3. Richtung umkehren: Sobald das gewünschte Design vorhanden ist, aufhören, aus dem Netzwerk zurück in den Source of Truth zu synchronisieren. Jetzt ist der Source of Truth der Chef. Die Ausführung (Kapitel 5) überträgt Änderungen nach außen ins Netzwerk.

4. Drift erkennen: Observability (Kapitel 6) beobachtet Geräte, die von dem abweichen, was der Source of Truth sagt, dass sie sein sollen. Wenn Drift auftritt, entscheiden Betreiber: Gerät korrigieren oder Source of Truth korrigieren?

Es gibt Werkzeuge wie Slurpit.io oder Erweiterungen für NetBox oder Nautobot, die sich auf dieses Problem konzentrieren.

Dieser Ansatz erfordert initialen Aufwand, vermeidet aber die Falle, den bereitgestellten Zustand als permanente Wahrheit zu behandeln. Der SoT entwickelt sich in Richtung sauberer Design-Absicht, auch wenn das Netzwerk Zeit braucht, um vollständig zu folgen. Natürlich kann man ihn weiterhin im Dry-Run-Modus verwenden, um zu überprüfen, dass das Netzwerk nicht gedriftet ist.

4.2.8. Daten-Lebenszyklus und Abgleich#

Daten werden veraltet. Ein Switch wird außer Betrieb genommen, ohne aus dem SoT entfernt zu werden. Eine IP-Adresse wird bei einem Vorfall manuell neu zugewiesen. Ein Auftragnehmer fügt während Notfallarbeiten ein VLAN zu einem Trunk-Port hinzu. Drei Monate später erinnert sich niemand mehr, und der SoT zeichnet etwas auf, das das Netzwerk seit Wochen nicht mehr ist.

Durchsetzung (Abschnitt 4.2.4) validiert Daten beim Eingang. Das ist nicht genug. Ein Datensatz, der zum Zeitpunkt der Erstellung korrekt war, kann einfach dadurch falsch werden, dass sich die Welt um ihn herum verändert. Ohne einen kontinuierlichen Abgleichsprozess verliert der SoT allmählich seine Glaubwürdigkeit: Teams hören auf, ihm zu vertrauen, beginnen ihre eigenen Tabellen zu pflegen, und die darauf aufgebaute Automatisierung beginnt still falsche Ergebnisse zu produzieren.

Das Abgleichsmuster

Abgleich bedeutet, den tatsächlichen Netzwerkzustand regelmäßig mit dem SoT zu vergleichen und jede Abweichung zu klassifizieren:

• Konfigurationsdrift: Ein Gerät weicht von seiner SoT-Absicht ab. Der SoT ist korrekt; das Netzwerk hat gedriftet. Den Ausführungsblock auslösen, um zu beheben.
• Nicht aufgezeichnete Änderung: Eine absichtliche Änderung wurde am Netzwerk vorgenommen, aber nicht im SoT aufgezeichnet. Das Netzwerk ist korrekt; der SoT ist veraltet. Den Betreiber alarmieren, die Absicht zu aktualisieren.
• Verwaister Datensatz: Der SoT hat ein Objekt (Gerät, Präfix, VLAN) für etwas, das nicht mehr im Netzwerk existiert. Zur Bereinigungsüberprüfung einreihen.

Jede Klasse erfordert eine andere Reaktion. Automatisierung kann Drift-Behebung übernehmen (innerhalb definierter Leitplanken). Nicht aufgezeichnete Änderungen erfordern menschliches Urteilsvermögen: War es eine Notfallkorrektur, die formalisiert werden sollte, oder eine unbefugte Änderung, die rückgängig gemacht werden sollte? Verwaiste Datensätze benötigen einen Bereinigungsworkflow, der nicht automatisch löscht, sondern den Kandidaten zur Überprüfung anzeigt.

Zu beobachtende Datenverfallsmuster

In der Praxis sind die häufigsten Quellen für SoT-Veralterung:

• Außer Betrieb genommene Geräte nicht entfernt: Der SoT hat einen Gerätedatensatz mit einer Management-IP, aber das Gerät wurde physisch entfernt. Automatisierung, die auf diese IP abzielt, schlägt fehl oder erreicht, noch schlimmer, ein Gerät, das mit einer anderen Rolle neu bereitgestellt wurde.
• Manuell neu zugewiesene IPs: Eine im SoT als zu Gerät A gehörend aufgeführte IP wird jetzt von Gerät B verwendet, das bei einem Vorfall zugewiesen wurde. Sowohl der SoT als auch das IPAM können intern konsistent, aber in Bezug auf das tatsächliche Netzwerk falsch sein.
• VLAN-Ausweitung: Ein VLAN wurde für eine definierte Gruppe von Switches bereitgestellt, aber während der Fehlerbehebung wurde es zusätzlichen Trunks hinzugefügt. Die SoT-Absicht stimmt nicht mehr mit der tatsächlichen Mitgliedschaft überein.

Abgleichsfrequenz

Nicht alle Daten altern mit der gleichen Rate. Geräteinventar ändert sich langsam; Betriebszustand ändert sich ständig. Ein praktischer Ansatz ist es, die Abgleichskadenz nach Datentyp zu staffeln: Geräteinventar täglich abgeglichen, IP-Zuweisungen stündlich abgeglichen, VLAN-Mitgliedschaft nach jedem Änderungsereignis und in einem täglichen Batch-Sweep abgeglichen.

Brownfield-Einführung (Abschnitt 4.2.7) ist eine einmalige Migration. Abgleich ist der operative Prozess, der den SoT nach dem Go-live glaubwürdig hält. Teams, die den Abgleich überspringen, werden feststellen, dass das Vertrauen in den SoT innerhalb von Monaten erodiert und die darauf aufgebaute Automatisierung still beginnt, falsche Ergebnisse zu produzieren.

Der SoT als Live-Abhängigkeit

Es gibt einen strukturellen Unterschied zwischen einem SoT, der als Referenz verwendet wird (Automatisierung liest ihn zu Beginn eines Workflows), und einem SoT, der als Live-Abhängigkeit verwendet wird (Automatisierung liest ihn bei jedem Schritt eines Workflows und vertraut darauf, dass Daten aktuell sind). Beide Muster sind gültig, aber das zweite schafft operative Anforderungen, die das erste nicht hat.

Wenn der Executor oder Orchestrator das Geräteinventar beim Workflow-Start aus dem SoT liest und dann über 200 Geräte hinweg auffächert, arbeitet er von einem Snapshot aus. Wenn ein Gerät während des Laufs außer Betrieb genommen wird oder eine IP-Adresse zwischen dem Snapshot-Lesen und dem Ausführungsschritt neu zugewiesen wird, handelt die Automatisierung auf veralteten Daten. Für kurze Workflows ist das meist akzeptabel. Für lang laufende Workflows (Firmware-Upgrades, die stundenlang laufen, Bereitstellungsläufe, die sich über Wartungsfenster erstrecken), ist das Veralterungsfenster erheblich.

Die Abhilfe besteht darin, SoT-Verfügbarkeit als Abhängigkeit zu behandeln, nicht als Annahme:

• Der Orchestrator sollte validieren, dass das SoT-Lesen erfolgreich war und einen aktuellen Datensatz zurückgegeben hat (durch Prüfung der letzten Synchronisierungszeitstempel oder des eigenen Health-Endpunkts des SoT), bevor ein Fan-out-Schritt gestartet wird.
• Für lang laufende Workflows sollte der SoT bei jeder wichtigen Workflow-Phase erneut gelesen werden, nicht nur einmal zu Beginn.
• Wenn der SoT nicht verfügbar ist, sollte der Workflow sauber mit einem klaren Fehler scheitern und nicht mit einem Snapshot unbekannten Alters fortfahren.

Das bedeutet auch, dass der SoT selbst für Verfügbarkeit ausgelegt sein muss. Ein SoT, der die schreibende Autorität für alle Automatisierungen ist, aber keine Hochverfügbarkeitskonfiguration hat, ist ein Single Point of Failure für die gesamte Automatisierungsplattform. Abschnitt 4.2.9 behandelt spezifische Lösungen; Kapitel 11 behandelt das Verfügbarkeitsdesign für die Plattform insgesamt.

4.2.9. Lösungslandschaft#

Es gibt viele Source-of-Truth-Produkte. Manche sind Open Source, manche kommerziell. Manche sind Allzweck, manche spezialisiert auf bestimmte Domänen wie IP-Management. Dies ist ein Snapshot von Anfang 2026: Die Landschaft ändert sich ständig, daher immer aktuelle Fähigkeiten und Dynamik prüfen, bevor eine Entscheidung getroffen wird.

4.2.9.1. Open-Source-Lösungen#

4.2.9.2. Kommerzielle Lösungen#

Alle oben aufgeführten Open-Source-Lösungen haben auch ein kommerzielles Angebot.

4.2.9.3. Spezialisierte Plattformen#

4.2.9.4. Auswahlkriterien#

Bei der Evaluierung von Source-of-Truth-Lösungen folgende Ausrichtungsfaktoren berücksichtigen:

• Skalierungsanforderungen: Anzahl der Geräte (Hunderte vs. Hunderttausende), Änderungsrate, Abfragevolumen
• Datenmodell-Anforderungen: Relationale Struktur (NetBox, Nautobot) vs. Graph-Beziehungen (Infrahub) vs. flexibler Dokumentenspeicher
• Integrations-Ökosystem: Bestehende Werkzeuge (Monitoring, ITSM, Cloud-Plattformen), die Daten föderieren müssen
• Team-Expertise: Python/Django-Vertrautheit, Präferenz für Low-Code-Plattformen, Komfort mit Git-Workflows
• Betriebsmodell: Selbst gehostet vs. SaaS, Änderungsgenehmigungsprozesse, RBAC-Anforderungen
• Entwicklungstrajektorie: Brownfield-Migrationspfad, Schema-Erweiterbarkeit, API-Stabilität

4.3. Implementierungsbeispiel#

4.3.1. Anwendungsfall: Aufbau des SoT für das Campus-Netzwerk#

Wir kehren zum Campus-Netzwerk zurück, das in Kapitel 3 vorgestellt wurde. Mit ungefähr 800 Access- und Distribution-Switches von Cisco, Arista und HPE, die über mehrere Gebäude verteilt sind, bearbeitet das Betriebsteam einen stetigen Strom von Serviceanfragen: neue VLANs, IP-Subnetz-Zuweisungen, Routing-Richtlinienaktualisierungen und Änderungen der Zugangskontrolle. Bevor irgendetwas davon zuverlässig automatisiert werden kann, müssen die Daten an einem konsistenten, maßgeblichen Ort sein.

Heute betreibt der Campus drei separate Systeme, die jeweils einen Teil des Gesamtbilds besitzen:

• Infoblox: Maßgebliches IPAM, das IP-Adresszuweisungen, Präfixzuweisungen und DNS über alle Campus-Subnetze verwaltet
• ServiceNow: Asset-Inventar und CMDB, das Switch-Standorte, Hardware-Modelle, Gebäudezuweisungen und Wartungshistorie verfolgt
• Campus-Switches: Die tatsächliche laufende Konfiguration, verteilt über 800 Geräte ohne eine einzige konsolidierte Ansicht dessen, was wo bereitgestellt ist

Herausforderung: Wenn das Anwendungsteam eine Anfrage für ein neues VLAN-Servicesegment einreicht, muss der Netzwerkingenieur manuell Infoblox abfragen, um ein verfügbares Subnetz zu finden, ServiceNow, um zu wissen, welche Switches sich im Zielgebäude befinden, und Secure Shell (SSH)-Sitzungen auf den Geräten, um aktuelle VLAN-Zuweisungen zu prüfen. Configuration Drift häuft sich an, weil es keine einzige Übereinstimmung darüber gibt, was der beabsichtigte Zustand jedes Switches sein soll. Das Hinzufügen einer neuen Anbieter-Designvorlage erfordert das Aktualisieren von Dokumentation an mehreren Stellen ohne Konsistenzgarantie.

Lösung: Nautobot als föderierter Netzwerk-Source-of-Truth einsetzen, der sowohl mit Infoblox als auch mit ServiceNow integriert, aktuellen Zustand von den Campus-Switches bezieht und das netzwerkspezifische Datenmodell hinzufügt, das weder Infoblox noch ServiceNow bereitstellen kann: VLAN-Definitionen, anbieter­spezifische Konfigurationsvorlagen, Designmuster für die Access- und Distribution-Schichten und das Serviceanfrage-Datenmodell, das eine Geschäftsanfrage mit den technischen Objekten verknüpft, die vorhanden sein müssen, bevor der Executor ein einziges Playbook ausführen kann.

Dieses Beispiel ist illustrativ, nicht vorschreibend. Es gibt viele gültige SoT-Produkte und Architekturen, die dieses Szenario lösen könnten. Der Punkt ist zu demonstrieren, wie die sechs Bausteine: Modellierung, Konsumierung, Durchsetzung, Versionierung, Aggregation und Design-Driven zusammen in einem realen Szenario funktionieren. Der SoT der eigenen Organisation wird wahrscheinlich anders aussehen, basierend auf vorhandenen Werkzeugen, Team-Expertise und Einschränkungen.

4.3.2. Lösungsarchitektur#

graph TB
    IPAM["Infoblox<br/>Maßgebliches IPAM<br/>IP-Bereiche, DNS"]
    CMDB["ServiceNow<br/>Maßgebliches CMDB<br/>Assets, Standorte, Metadaten"]
    DEVICES["🖧 Campus-Switches<br/>Cisco, Arista, HPE<br/>~800 Geräte"]
    
    SLURPIT["Slurpit<br/>Brownfield-Discovery<br/>Konfig-Extraktion"]
    
    subgraph NAUTO ["🔗 Nautobot (Aggregations-Hub)"]
        direction TB
        AGG["Aggregationsschicht<br/>Autoritätsregeln<br/>Konfliktlösung"]
        SOT["Konsolidierter SoT und Datenerweiterung<br/>Geräte, IPs, Standorte<br/>Beziehungen"]
        API["Konsumierungs-APIs<br/>REST, GraphQL<br/>Webhooks"]
    end
    
    EXEC["🚀 Ausführungssystem<br/>Konfigurationsgenerierung<br/>Gerätebereitstellung"]
    OBS["👁️ Observability<br/>Zustandsvalidierung<br/>Drift-Erkennung"]
    UI["🖥️ Präsentation<br/>Web UI, CLI<br/>Dashboards"]
    
    IPAM -->|Webhooks/Polling<br/>IP-Daten| AGG
    CMDB -->|Webhooks/Polling<br/>Asset-Daten| AGG
    DEVICES -->|SSH/NETCONF<br/>Gerätezustand| SLURPIT
    SLURPIT -->|Transformierte Daten<br/>Initialer Bootstrap| AGG
    
    AGG --> SOT
    SOT --> API
    
    API -->|Absichtsabfragen| EXEC
    API -->|Konfigurationsvorlagen| EXEC
    API -->|Datenzugriff| UI
    
    OBS -->|Zustandsdrift| API
    API -->|Inventar| OBS
    
    EXEC -.->|Konfigurationen deployen| DEVICES
    OBS -.->|Zustand überwachen| DEVICES

Die wichtigste Erkenntnis: Nautobot ersetzt Infoblox oder ServiceNow nicht. Es aggregiert ihre Daten, löst Konflikte und dient als die einzige API, die nachgelagerte Systeme (Ausführung, Observability, Präsentation) konsumieren. Diese Trennung der Zuständigkeiten ermöglicht es, dass jedes System ein Bestes-der-Klasse-Werkzeug ist.

Wie die 6 Komponenten zusammenarbeiten#

Modellierung: Jede Datenquelle kommt mit ihrem eigenen Datenmodell mit einigen Überschneidungen, die eine Datenverknüpfung über Identifier ermöglichen. Die Verantwortung ist verteilt, jede Datenquelle spezialisiert sich auf verschiedene Daten. Die Struktur muss partielle Daten erlauben, bis alle Informationen konsolidiert sind (z.B. kann ein Gerät in Nautobot vor der IP-Zuweisung existieren).

Konsumierung: Nautobot bietet eine REST-API und eine GraphQL-Schnittstelle für andere Geräte, um Daten konsistent von einem zentralen Punkt abzufragen, anstatt mit allen Datenquellen integrieren zu müssen.

Durchsetzung: Nautobot setzt globale Validierung zur Konsistenz durch. Wenn IPAM sagt, 10.1.1.5 ist device-dal-01 zugewiesen, aber dieses Präfix für eine andere Region zugewiesen ist, wo das Gerät nicht hingehört, muss es markiert werden. Außerdem verhindert es verwaiste Daten: Eine IP aus Infoblox kann nicht zugewiesen werden, wenn das Gerät nicht in ServiceNow existiert (referentielle Integrität). Darüber hinaus warnt Soft-Validierung: “Gerät wurde in ServiceNow vor 30 Tagen zuletzt aktualisiert; möglicherweise veraltet” (ohne Blockierung), mit der Fähigkeit, Daten zu bereinigen.

Versionierung: Alle Änderungen als Changelog-Einträge verfolgt. Wenn sich ein Objekt ändert und IPAM automatisch eine IP neu zuweist, zeichnet Nautobot auf “IPAM-Webhook: IP 10.1.1.5 device-dal-02, Interface eth1.1 am 2024-02-08T14:32:00Z zugewiesen”, was ermöglicht, warum ein Gerät seine aktuelle IP hat, durch die Geschichte nachzuverfolgen. Allerdings ist die Rollback-Kapazität begrenzt, da es keinen Mechanismus gibt, auf einen früheren Zeitpunkt zurückzukehren (Hinweis: die Nautobot VCS-App ermöglicht ausgefeiltere Fähigkeiten, die hier der Einfachheit halber nicht behandelt werden).

Aggregation: Dies ist ein wesentlicher Aspekt dieser Lösung, da es mehrere zu verbindende Datenquellen gibt. Nautobot priorisiert Infoblox für IP-Daten (es ist das maßgebliche IPAM). Für Asset-Metadaten (Garantie, Kostenstelle) ist ServiceNow maßgeblich, und Nautobot verwendet dies zur Lösung von Unstimmigkeiten. Die Synchronisierungsstrategie könnte so aussehen:

• ServiceNow → Nautobot: Periodische Synchronisierung alle 4 Stunden (leichte Verzögerung bei Asset-Metadaten tolerierbar)
• Infoblox → Nautobot: Echtzeit-Webhooks für IP-Änderungen (IPAM-Änderungen sind dringend, können nicht auf Polling warten)
• Netzwerkgeräte → Nautobot: Mit der Nautobot Onboarding-App werden Daten aus dem Netzwerk in Nautobot-Datenmodelle eingebunden (eventuelle Konsistenz akzeptabel) Darüber hinaus, wenn es einige Ausfälle gibt, könnte Nautobot einige Resilienz-Mechanismen anbieten wie:
• Wenn Infoblox für 2 Stunden ausgefallen ist, setzt Nautobot den Betrieb mit gecachten IP-Daten fort, markiert als “veraltet”
• Betreiber sehen Warnung: “IP-Daten von vor 2 Stunden; IPAM aktuell nicht verfügbar; neue Zuweisung aufgeschoben”
• Sobald Infoblox wiederhergestellt ist, werden ausstehende Zuweisungen atomar verarbeitet

Design-Driven: Mit der Nautobot Design Builder App bietet Nautobot eine High-Level-Schnittstelle zur Erfüllung einer neuen VLAN-Serviceanfrage. Der Betreiber gibt High-Level-Absicht an: { "vlan_name": "app-payments", "subnet_size": "/24", "location": "building-b", "vendors": ["arista", "cisco"] }. Dann erweitert eine Designvorlage dies: VLAN-Objekt in Nautobot erstellen, ein verfügbares /24-Präfix aus Infoblox für den IP-Bereich von building-b anfordern, anbieterspezifische Konfigurationsvorlagen automatisch generieren (Arista-EOS-Syntax für Distribution-Switches, Cisco-IOS-XE-Syntax für Access-Switches), ServiceNow abfragen, um zu ermitteln, welche der 800 Campus-Switches physisch in building-b sind, was zu allen technischen Objekten führt, die der Executor benötigt, bevor er ein einziges Playbook ausführt.

4.3.3. Implementierungsablauf#

Erstmalige Datenladung

1. Infoblox-Import: Nautobot verbindet sich mit der Infoblox-API → zieht alle IP-Bereiche, Reservierungen, DNS-Einträge
2. ServiceNow-Import: Nautobot verbindet sich mit dem ServiceNow-CMDB → zieht alle IT-Assets, Standorte, Beziehungen
3. Brownfield-Netzwerkerkennung mit Slurpit: Slurpit.io verbindet sich mit bestehenden Netzwerkgeräten, um den aktuellen Konfigurationszustand zu extrahieren:
   • Geräteinventar (Modelle, Seriennummern, Software-Versionen)
   • Schnittstellenkonfigurationen und Betriebszustand
   • IP-Adressierung und VLAN-Zuweisungen
   • Routing-Protokollkonfigurationen
   • Transformiert Gerätekonfigurationen in Nautobot-kompatible Datenmodelle
4. Divergenzerkennung und -lösung: Nautobot-Auditprozess korreliert Daten aus allen drei Quellen (Infoblox, ServiceNow, Slurpit):
   • Konfliktbeispiel: Geräte-Interface zeigt 10.1.1.5/24, aber Infoblox zeigt diese IP einem anderen Gerät zugewiesen
   • Lösungsworkflow: Nautobot markiert 47 Konflikte zur menschlichen Überprüfung
     • Netzwerkingenieur bewertet jeden: “Gerätezustand vertrauen” oder “IPAM vertrauen; Gerät muss korrigiert werden”
     • Governance-Regeln angewendet: “Gerät für Access-Ports vertrauen, IPAM für Infrastruktur-IPs vertrauen”
   • Batch-Lösung: Ähnliche Konflikte mit konsistenter Richtlinie gelöst
5. Einheitliche Schema-Befüllung: Nautobot fusioniert alle drei Quellen: devices[*].{ name, location_id, ipv4_address, serial_number, cost_center } mit validierten, konfliktgelösten Daten

Live-Betrieb

1. Neue VLAN-Serviceanfrage: Das Anwendungsteam reicht eine Anfrage in ServiceNow ein. Nautobot fängt den Webhook ab, erstellt die VLAN- und Präfixobjekte, fragt Infoblox nach dem nächsten verfügbaren /24 im Adressbereich von building-b ab, weist ihn automatisch zu und stempelt den Datensatz mit Antragsteller, Genehmiger und Zeitstempel. Der Ausführungsblock kann nun Nautobot für jeden Datenpunkt abfragen, den er benötigt, um den Dienst auf allen Ziel-Switches bereitzustellen.
2. Neuer Campus-Switch eingebunden: Betreiber erstellt den Asset-Eintrag in ServiceNow. Nautobot fängt den Webhook ab, erstellt das Geräteobjekt mit Standort-, Anbieter- und Rollenmetadaten, fragt Infoblox nach einer Management-IP im Site-Management-Bereich ab und weist die entsprechende Designvorlage basierend auf Geräterolle und Anbieter zu. Der Switch ist im SoT registriert und für zukünftige Bereitstellungen geeignet, bevor jemand die CLI berührt.
3. Infoblox-Wartungsfenster: IPAM geht für 2 Stunden offline. Nautobot zeigt gecachte Daten “IP-Daten gültig ab 14:30 UTC; Aktualisierung ausstehend”. Betreiber können weiterhin Geräteinventar und VLAN-Definitionen abfragen, aber neue IP-Zuweisungen werden aufgeschoben. Wenn Infoblox zurückkehrt, stellt sich die ausstehende Zuweisungswarteschlange auf und verarbeitet atomar.

Umgang mit Inkonsistenz und periodische Drift-Erkennung

Nach dem erstmaligen Onboarding überwacht Nautobot kontinuierlich auf Divergenz über alle drei Datenquellen:

1. Laufende Synchronisierung: Neben ereignisgesteuerten Updates, die ausgelöst werden, wenn Änderungen auftreten, laufen periodische Synchronisierungen alle 4-6 Stunden:

   • Infoblox-Synchronisierung: Webhook-gesteuert für IP-Änderungen + periodischer Abgleich
   • ServiceNow-Synchronisierung: Periodisches Polling für Asset-Metadaten-Updates
   • Slurpit-Discovery: Periodisches Geräte-Polling, um den tatsächlichen Netzwerkzustand zu erfassen

2. Nautobot-Audit und -Korrelation: Nautobot’s Auditprozess vergleicht Daten aus allen Quellen, um Inkonsistenzen zu erkennen:

   • Datenquellenkonflikt: Geräte-Interface-IP weicht von Infoblox-Zuweisung ab
   • Configuration Drift: Gerätezustand weicht von Nautobot-Absicht ab (NTP-Server geändert, VLAN zu Trunk hinzugefügt)
   • Veraltete Metadaten: ServiceNow-Asset zuletzt vor 90 Tagen aktualisiert (potenzielle Veralterung)

3. Divergenz-Klassifizierung und -Behebung:

   • Typ 1 - Configuration Drift: Gerät weicht von Nautobot-Absicht ab → Ausführung auslösen, um Gerät zu korrigieren
     • Beispiel: NTP-Server auf Gerät geändert → Ausführung regeneriert Konfiguration und überträgt Korrektur
   • Typ 2 - Absichtsveralterung: Absichtliche Änderung noch nicht in Nautobot widergespiegelt → Betreiber alarmieren, SoT zu aktualisieren
     • Beispiel: Betreiber hat VLAN bei Vorfall manuell hinzugefügt → Nautobot aktualisieren, um aktuelle Absicht widerzuspiegeln
   • Typ 3 - Externe Autoritätsinkongruenz: Konflikt zwischen maßgeblichen Quellen (Infoblox vs. Geräterealität)
     • Beispiel: IP-Zuweisungsinkongruenz → Menschliche Entscheidung basierend auf Governance-Regeln erforderlich

4. Automatisierte vs. manuelle Behebung:

   • Auto-Behebung: Vorab genehmigte Änderungen (NTP, DNS, Syslog-Server) werden automatisch über die Ausführung korrigiert
   • Manuelle Genehmigung: Kritische Änderungen (BGP-Konfiguration, Routing-Protokolle, Sicherheitsrichtlinien) erfordern menschliche Überprüfung vor der Korrektur
   • Eskalation: Unlösbare Konflikte oder wiederholte Drift-Muster werden an das Netzwerkteam eskaliert

5. Audit-Trail: Alle erkannten Divergenzen, Lösungen und Behebungsmaßnahmen für Compliance und Fehlerbehebung protokolliert

4.3.4. Ansatz-Kompromisse#

Vorteile dieses Ansatzes#

Einschränkungen und Grenzen#

Es gibt andere Wege und Lösungen, die für den eigenen Anwendungsfall besser passen könnten. Eigene Entscheidungen auf Basis der eigenen Bedürfnisse und Anforderungen treffen. Es gibt immer Kompromisse zu berücksichtigen.

4.4. Zusammenfassung#

Die verwaiste Firewall-Regel in der Eröffnungsgeschichte war kein Konfigurationsfehler. Niemand hat seinen Job schlecht gemacht. Die Regel blieb, weil es kein System gab, das das VLAN mit dem Dienst und der Firewall-Richtlinie verband. Als das VLAN entfernt wurde, existierte diese Verbindung nicht, also gab es nichts, das die Bereinigung der Regel ausgelöst hätte. Der Source of Truth ist das System, das diese Verbindungen explizit macht.

Sechs Funktionalitäten bauen dieses System auf. Modellierung definiert, wie das Netzwerk aussehen soll und auf welchem Abstraktionsniveau. Design-Driven übersetzt eine Geschäftsanfrage (“Zweigstelle Dallas hinzufügen”) in die 50+ technischen Objekte, die der Executor benötigt, bevor er ein Gerät berührt. Konsumierung macht diese Absicht konsistent für Menschen, Automatisierungs-Workflows und andere Systeme verfügbar. Durchsetzung stellt sicher, dass Daten, die in den SoT eingehen, gültig sind, bevor sie downstream falschen Netzwerkzustand erzeugen können. Versionierung zeichnet jede Änderung mit Autor, Grund und Zeitstempel auf und macht den SoT prüfbar und wiederherstellbar. Aggregation verbindet den SoT mit den maßgeblichen Systemen, die bereits Teile der Daten besitzen: IPAM für Adressen, CMDB für Assets, Circuit-Anbieter für Konnektivität.

Das Campus-Implementierungsbeispiel zeigte alle sechs zusammenarbeitend: Nautobot als Federations-Hub, Infoblox und ServiceNow als maßgebliche Quellen für ihre jeweiligen Domänen, Designvorlagen, die eine VLAN-Serviceanfrage in alles übersetzen, was für die automatisierte Bereitstellung benötigt wird. Das Ergebnis ist nicht nur eine Datenbank des Netzwerkzustands. Es ist die einzige Referenz, die jeder andere Baustein konsultiert, um zu wissen, wie das Netzwerk aussehen soll.

Kapitel 5 nimmt diese Absicht und setzt sie in Aktion um: Der Ausführungsblock liest aus dem SoT und überträgt Änderungen ins Netzwerk, mit den Konsistenzgarantien und dem Rollback-Verhalten, das die Versionierungsfunktionalität des SoT ermöglicht.

Referenzen und weiterführende Literatur#

Datenmodellierung und Schema-Standards

• IETF RFC 6020 & RFC 7950: YANG-Datenmodellierungs-Sprachstandard
• IETF YANG Models: Repository von Standard-YANG-Modellen einschließlich IETF, IEEE und OpenConfig
• OpenConfig: Communitygesteuerte, anbieter­neutrale Konfigurationsmodelle
• NETCONF (RFC 6241): Netzwerkkonfigurationsprotokoll, komplementär zu YANG

APIs und Datenkonsumierung

• GraphQL Specification
• gRPC: Modernes RPC-Framework für leistungsstarke APIs
• REST API Design Guide: Microsofts Best Practices für Versionierung, Paginierung
• OAuth 2.0 (RFC 6749) & OpenID Connect (RFC 6750): Authentifizierungs-/Autorisierungsstandards

Datenqualität und Validierung

• Data Quality Fundamentals (DAMA DMBOK): Enterprise-Datenqualitätsrahmen
• JSON Schema: Deklarativer Schema-Validierungsstandard
• YANG Constraints (RFC 6020, Abschnitt 8.2.4): Netzwerkspezifische Validierungsmuster

Versionierung, Audit und Änderungsmanagement

• Pro Git (Scott Chacon & Ben Straub): Versionskontrollkonzepte und Designmuster
• The Phoenix Project (Gene Kim, Kevin Behr, George Spafford): Änderungsmanagement und operative Disziplin
• Semantic Versioning: Versionierungsstrategie für APIs und Datenmodelle

Datenintegration und Aggregation

• Enterprise Integration Patterns (Gregor Hohpe & Bobby Woolf): Datenintegrationsarchitekturmuster
• Master Data Management (David Loshin): Föderierte Governance-Rahmen

Netzwerkprogrammierbarkeit und Automatisierung

• Network Programmability and Automation, 2nd Edition (Jason Edelman, Matt Oswalt, Scott S. Lowe, Christian Adell): Grundlagenkonzepte für Netzwerkautomatisierung
• Infrastructure as Code, 2nd Edition (Kief Morris): Infrastrukturkonfigurationen als versionierten Code behandeln

Verteilte Systeme und Skalierbarkeit

• Designing Data-Intensive Applications (Martin Kleppmann): Skalierbarkeit, Konsistenz und API-Designmuster
• Distributed Systems (Andrew S. Tanenbaum & Maarten van Steen): Grundlegende Konzepte für föderierte Systeme

💬 Found something to improve? Send feedback for this chapter