Infrastructure Graphs: Network Graph Datenmodell für Visualisierung

Infrastructure Graphs sind der pragmatische nächste Schritt nach klassischen Netzwerkdiagrammen, Tabellen und CMDB-Listen: Statt „ein Bild pro Zeitpunkt“ modellieren Sie Ihre Infrastruktur als Network Graph – also als Graph-Datenmodell aus Knoten (Nodes) und Kanten (Edges), das Topologie, Abhängigkeiten und Pfade maschinenlesbar beschreibt und daraus beliebige Visualisierungen ableiten kann. Genau das löst ein wiederkehrendes Problem im Betrieb: Diagramme veralten, sobald sich Links, Policies oder Services ändern. Ein Graph dagegen kann kontinuierlich aus Source-of-Truth-Systemen (z. B. NetBox), aus Telemetrie (LLDP, Routing-States, Flows) und aus Konfigurations-Parsing befüllt werden und bietet dann „Living Views“: Site-Topologien, Security-Zonen, Pfadmodelle, Service Maps, Failure Domains oder Change-Impact-Ansichten – jeweils passend zum Use Case. Der Schlüssel ist das Datenmodell: Welche Knotentypen gibt es? Welche Beziehungstypen sind erlaubt? Welche Attribute sind kanonisch, welche nur Beobachtungen? Und wie verhindern Sie, dass aus dem Graphen die nächste „Wahrheit“ neben der Wahrheit wird? Dieser Artikel zeigt Best Practices für Infrastructure Graphs: wie Sie ein robustes Network-Graph-Datenmodell entwerfen, Datenquellen sauber integrieren, Visualisierung skalierbar machen und die Grenzen (Intent vs. Ist-Zustand, ECMP, Overlays, stateful Controls) so abbilden, dass der Graph im Alltag wirklich hilft – statt neue Diagramm-Lügen zu erzeugen.

Warum ein Network Graph besser skaliert als klassische Dokumentation

Klassische Netzwerkdokumentation ist oft dokumentzentriert: Diagramme, Wikiseiten, Tabellen. Das ist für kleine Umgebungen ausreichend, skaliert aber schlecht, sobald mehrere Domänen (WAN, Campus, DC, Cloud), Overlays (SD-WAN, EVPN/VXLAN, SASE) und Sicherheitskontrollen zusammenkommen. Infrastructure Graphs sind dagegen datenorientiert: Sie speichern nicht „ein Diagramm“, sondern Beziehungen. Aus diesen Beziehungen können Sie beliebige Diagramme und Abfragen erzeugen, z. B. „Welche Services hängen an diesem Link?“, „Welche Trust Boundary überquert dieser Flow?“, „Welche SPOFs existieren für Standort X?“ oder „Wo sind Capture Points für Troubleshooting?“

• Einmal modellieren, vielfach visualisieren: dieselben Daten erzeugen Overview, Drilldowns und Audit-Views.
• Automatisierung: Graphdaten sind maschinenlesbar und damit ideal für CI-Checks, Drift-Reports und Change-Impact-Analysen.
• Abfragen statt Suchen: statt „wo steht das im Wiki?“ fragen Sie den Graphen direkt.
• Lebenszyklen: planned/active/decommissioned lassen sich als Zustände auf Knoten und Kanten führen.

Graph-Grundlagen: Property Graph vs. RDF – und was für Infrastruktur passt

Im Infrastrukturkontext begegnen Ihnen meist zwei Graph-Paradigmen: der Property Graph (Nodes/Relationships mit Eigenschaften) und der RDF Graph (Triples: Subjekt–Prädikat–Objekt). Beide funktionieren, aber mit unterschiedlichen Stärken.

Property Graph: pragmatisch für Betrieb und Visualisierung

Property Graphs sind im Netzwerkbetrieb beliebt, weil sie sehr natürlich abbilden: „Device A CONNECTED_TO Device B“ mit Properties wie speed, status, vlan_bundle, circuit_id. Graphdatenbanken wie Neo4j sind typische Vertreter; Einstieg: Neo4j Dokumentation.

• Vorteile: flexible Eigenschaften, einfache Abfragen, schnelle Visualisierung, gut für Topologiegraphen.
• Nachteile: Semantik/Standardisierung muss Ihr Team selbst definieren (Schema, Ontologie-Disziplin).

RDF: stark für Semantik und Wissensgraphen

RDF ist besonders stark, wenn Sie formale Semantik, Ontologien und Interoperabilität zwischen Domänen brauchen. Der Datenmodellstandard ist beim W3C beschrieben: RDF 1.1 Concepts and Abstract Syntax.

• Vorteile: klare Semantik, Ontologien, reasoning-fähige Modelle, gute Integration ins Semantic-Web-Ökosystem.
• Nachteile: höherer Modellierungsaufwand, oft komplexere Toolchains für „klassische“ NetOps-Use-Cases.

Für die meisten NetOps-Teams ist ein Property Graph der pragmatischste Start. Wenn Sie später semantische Interoperabilität brauchen, können Sie RDF als Exportformat oder als paralleles Wissensmodell ergänzen.

Der wichtigste Designsatz: Ein Graph ist ein Datenmodell, kein Diagramm

Ein Diagramm beantwortet eine Frage. Ein Graph ermöglicht viele Fragen. Genau deshalb müssen Sie im Datenmodell strikt trennen zwischen:

• Objekten (was existiert): Devices, Interfaces, Prefixe, VRFs, Circuits, Zonen, Services.
• Beziehungen (wie hängt es zusammen): CONNECTED_TO, ROUTES_TO, MEMBER_OF, ENFORCED_BY, DEPENDS_ON.
• Beobachtungen (was wurde gemessen): link_state, lldp_neighbor_seen_at, bgp_session_state, flow_count.
• Intent (was soll gelten): owner, role, approved_flows, redundancy_target, security_zone.

Wenn Sie Beobachtungen und Intent vermischen, entstehen „Diagramm-Lügen“: Der Graph wirkt autoritativ, aber seine Aussagen sind nicht eindeutig. Best Practice ist daher: Intent kommt aus Source of Truth und Architekturartefakten; Beobachtungen kommen aus Telemetrie und Parsing; beides wird im Graphen getrennt geführt.

Ein praxistaugliches Network-Graph-Datenmodell

Ein robustes Modell muss nicht riesig sein. Es muss konsistent sein. Ein guter Start ist ein Kernmodell aus wenigen Knotentypen und Beziehungstypen, das Sie später erweitern.

Knotentypen für Infrastructure Graphs

• Site: Standort/Datacenter/PoP (mit region, site_code, tenant, lifecycle).
• Rack: physischer Container (optional, wenn L1/Remote Hands relevant ist).
• Device: Switch/Router/Firewall/LB/Server (role, vendor, model, mgmt_ip, owner).
• Interface: Port/SVI/Tunnel (type, speed, description, admin_state).
• Link: optional als eigener Knoten, wenn Sie Links als „Objekte“ versionieren möchten (cable_id, media, path_diversity).
• Prefix/IP: IPAM-Objekte (vrf, status, purpose).
• VRF/VLAN/Zone: Segmentierungs- und Domänenobjekte (security_class, environment).
• Circuit: Provider-Leistung (carrier, circuit_id, demarc, sla).
• Service: Business-/App-Service (criticality, slo_class, owner, dependencies).
• ControlPoint: Enforcement/Insertion (Firewall, Proxy/WAF, SASE PoP, ZTNA Connector).

Beziehungstypen, die sich bewähren

• LOCATED_IN: Device → Rack → Site.
• HAS_INTERFACE: Device → Interface.
• CONNECTED_TO: Interface ↔ Interface (physisch/logisch, mit Properties).
• MEMBER_OF: Interface → LAG/PortChannel oder Device → Cluster/Pair.
• ASSIGNED_TO: Interface/IP → VRF/VLAN/Zone.
• USES_CIRCUIT: Edge Device/Interface → Circuit.
• ENFORCED_BY: Zone/FlowCategory → ControlPoint.
• DEPENDS_ON: Service → DNS/IdP/LB/DB/Network Segment.
• PATH_TO: abstrakte Pfadbeziehung zwischen Knoten (mit pfadset/ecmp-Attributen).

Schema-Disziplin: Regeln, die einen Graphen wartbar machen

Ein Graph ohne Schema-Disziplin wird schnell zum „Datensee mit Kanten“. Auch wenn Property Graphs schemalos wirken, brauchen Sie Teamregeln.

• Kontrolliertes Vokabular: Rollen, Zonen, Statuswerte, Relationship-Typen – keine Freitextwüste.
• Stabile Identifikatoren: interne IDs (z. B. NetBox id) plus kanonische Namen als Label; kein Matching nur über Namen.
• Lifecycle: planned/active/deprecated/decommissioned für Nodes und Edges.
• Quelle je Attribut: source=netbox, source=telemetry, source=configparse inkl. timestamp.
• Trennung von Observed vs. Intended: beobachtete Kanten dürfen Intent nicht überschreiben, sondern Abweichungen markieren.

Datenquellen anbinden: So füttern Sie den Infrastructure Graph zuverlässig

Ein Network Graph ist nur so gut wie seine Ingest-Pipeline. Bewährt hat sich ein mehrstufiger Ansatz: SoT-Daten liefern die Struktur und Identität; Telemetrie und Parsing liefern Beobachtungen; Validierung sorgt für Vertrauen.

Source of Truth: NetBox als DCIM/IPAM-Basis

NetBox ist in vielen Netzwerkteams die technische Quelle für Sites, Devices, Interfaces, IPAM und Circuits. Über die REST API lässt sich NetBox gut als „Graph Seeder“ nutzen: Objekte werden als Nodes angelegt, Beziehungen (z. B. Interface-Zuordnung, Site-Zuordnung) als Edges. Referenz: NetBox REST API Overview.

Telemetrie: LLDP, Routing-States, Streaming Telemetry

Telemetrie liefert vor allem Kanten: Nachbarschaften, Session-States, Link-Health. Modellgetriebene Ansätze (z. B. OpenConfig) reduzieren Vendor-Heterogenität; Einstieg: OpenConfig.

Config Parsing: Policies und Intent-Indikatoren

Konfigurationen enthalten Intent-nahe Informationen (VRFs, Route-Policies, ACL-Kategorien). Diese Daten sollten meist als „derived“ oder „observed“ in den Graphen gehen, damit Sie später Drift gegen den intendierten Zustand erkennen können.

Flow-Telemetrie: Service Maps und Kommunikationsmuster

Flow-Daten sind ideal, um Service-Graph-Kanten zu erkennen („Service A spricht mit Service B“), ohne gleich eine vollständige Regelwerksanalyse zu erzwingen. IPFIX als Standard ist in RFC 7011 beschrieben.

Visualisierung: Warum der Graph nicht automatisch ein gutes Diagramm ergibt

Ein häufiger Irrtum ist: „Wenn wir den Graphen haben, sind die Diagramme automatisch gut.“ In der Praxis brauchen Sie kuratierte Views, sonst erzeugen automatische Layouts Spaghetti-Pläne. Die Lösung ist dieselbe wie bei manueller Dokumentation: One Diagram per Question.

• Executive View: nur Domains, Hubs, Provider, Failure Domains.
• Site View: LLDP-Topologie pro Standort, mit Link-Health.
• Security View: Zonen als Container, ControlPoints, Flow-Kategorien.
• Troubleshooting View: Capture Points, Mirror Paths, relevante Kontrollpunkte.
• Path View: Pfadsets (ECMP) für definierte Critical Flows.

Der Graph liefert die Daten, aber die View definiert Filter, Aggregation und Layoutregeln.

Pfade modellieren: Connectivity, Routing und Observed Paths

Wenn Sie „Pfade“ im Graphen abbilden, müssen Sie sehr sauber definieren, was ein Pfad bedeutet. Für NetOps sind drei Tiefen sinnvoll:

• Connectivity Path: es existiert eine Verbindungskette (rein topologisch).
• Routing Path: berechnete Next-Hop-Pfade basierend auf RIB/FIB und IGP/BGP-Topologie.
• Observed Path: tatsächlich beobachtete Pfade (Flows, Traces, In-Band Signale).

Best Practice: Speichern Sie Pfade nicht nur als „A→B“, sondern als Pfadobjekt oder als Edge mit Eigenschaften: path_type, ecmp_group, constraints (mtu, latency), observed_window, confidence_score.

ECMP, Anycast, Overlays: Die Grenzen müssen im Modell sichtbar sein

Infrastructure Graphs werden gefährlich, wenn sie Eindeutigkeit suggerieren, wo keine Eindeutigkeit existiert. Modellieren Sie diese Realitäten explizit:

• ECMP: Pfad ist ein Set; speichern Sie mehrere Next-Hops oder eine Gruppe statt eines Single-Pfads.
• Anycast: Ziel ist eine Gruppe; modellieren Sie Anycast-Serviceknoten mit mehreren Endpunkten.
• Overlays: Underlay-Graph und Overlay-Graph strikt trennen; Gateways (VTEP, SD-WAN Edge, SASE On-Ramp) als Übergänge markieren.
• Stateful Controls: Firewalls/NAT/Load Balancer als stateful kennzeichnen, damit Asymmetrie-Risiken sichtbar sind.

Governance: Wie Sie verhindern, dass der Graph selbst zur „Diagramm-Lüge“ wird

Ein Graph ist mächtig, aber ohne Governance wird er schnell untrusted. Die wichtigsten Governance-Mechanismen sind:

• Field Ownership: welche Attribute sind SoT-owned, welche telemetry-owned, welche derived?
• Review Gates: große Modelländerungen (z. B. neue Relationship-Typen) gehen durch Review wie Code.
• Reconciliation: regelmäßige Abgleiche (Orphans, Dubletten, Status-Drift, Neighbor-Plausibilität).
• Versionierung: Schema- und Modellversionen („was hat sich geändert und warum“).
• Security: Zugriff auf Graphdaten ist privilegiert; Topologie und Flows sind sensitive Informationen.

Praktische Checks: Qualitätssicherung für Infrastructure Graphs

• Orphan Nodes: Telemetrie sieht Device, SoT kennt es nicht (oder umgekehrt).
• Impossible Edges: Interface-Typen passen nicht (z. B. „SM-Fiber“ auf Kupferport), oder Sites sind unplausibel.
• Duplicate Identity: zwei Nodes repräsentieren dasselbe Asset (Serial/SoT-ID-Kollision).
• Stale Observations: LLDP-Neighbor älter als definierter Threshold, aber noch als „active“ markiert.
• ControlPoint Gaps: Flows zeigen Kommunikation über eine Boundary, aber kein Enforcement-Punkt ist modelliert.

Best Practices für den Einstieg: klein starten, nutzbar liefern

Viele Teams scheitern, weil sie sofort „den perfekten Graphen“ bauen wollen. Besser ist ein iterativer Start mit klarem Nutzen:

• Phase 1: SoT-Seed (Sites, Devices, Interfaces, Circuits) + LLDP-Edges → Site-Topologie-Views.
• Phase 2: Link-Health (status, errors, flaps) → Troubleshooting-Views.
• Phase 3: Routing-States → Control-Plane-Views und Pfadsets für wenige Critical Flows.
• Phase 4: Flow-Telemetrie → Service Maps (kommuniziert mit) + Change-Impact.
• Phase 5: Governance/CI (Schema-Checks, Drift-Alerts, Review-Workflows) → langfristiges Vertrauen.

Checkliste: Infrastructure Graphs als Network Graph Datenmodell für Visualisierung

• Das Hauptkeyword „Infrastructure Graphs“ wird als datenorientiertes Modell verstanden (Nodes/Edges), nicht als einzelnes Diagramm
• Graph-Paradigma ist gewählt (Property Graph pragmatisch; RDF optional für Semantik), mit Referenzen wie Neo4j Dokumentation und RDF 1.1 Concepts
• Kernmodell ist definiert (Site, Device, Interface, Prefix, VRF/VLAN/Zone, Circuit, Service, ControlPoint)
• Relationship-Typen sind kontrolliert und konsistent (CONNECTED_TO, ASSIGNED_TO, DEPENDS_ON, ENFORCED_BY)
• Observed vs. Intended ist getrennt (Telemetrie/Parsing als Observations, SoT als Intent)
• Datenquellen sind sauber integriert (SoT via NetBox API: NetBox REST API, Telemetrie via OpenConfig: OpenConfig, Flows via IPFIX: RFC 7011)
• Visualisierung ist kuratiert („One Diagram per Question“) statt automatisch alles zu plotten
• Pfade sind modelliert mit Unsicherheiten (ECMP als Pfadsets, Anycast als Gruppen, Overlays getrennt)
• Governance verhindert Graph-Lügen (Field Ownership, Reconciliation, Versionierung, Review Gates)
• Security/Datenschutz ist berücksichtigt (Least Privilege, Segmentierung, Retention, Audit Trail für Graphdaten)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.