February 25, 2026

Diagramme aus Daten generieren: Automatisierung mit NetBox & Tools

Wer Netzwerkdiagramme regelmäßig manuell zeichnet, kennt das Problem: Kaum ist der Plan „fertig“, kommt der nächste Change – ein neuer Uplink, ein zusätzliches VLAN, ein neuer Standort, ein umgezogener Switchport. Genau hier setzt der Ansatz „Diagramme aus Daten generieren“ an. Statt Topologien, VLAN-Übersichten oder Standortpläne als statische Bilder zu pflegen, werden Diagramme automatisiert aus einer verlässlichen Datenquelle erzeugt. In modernen Netzwerken ist diese Datenquelle häufig NetBox, weil dort Geräte, Interfaces, Kabelverbindungen und IPAM strukturiert modelliert werden. Der Mehrwert ist enorm: Diagramme werden reproduzierbar, versionierbar und (bei guter Prozessintegration) automatisch aktuell. Das reduziert „Spaghetti-Pläne“, beschleunigt Incident Response und entlastet Teams, weil der Pflegeaufwand sinkt. In diesem Praxisleitfaden erfahren Sie, wie Sie Diagramme aus NetBox-Daten generieren: welche Diagrammtypen sich eignen, welche Tools (Mermaid, PlantUML, Graphviz, draw.io/diagrams.net) sinnvoll sind, wie ein Teamworkflow aussieht und welche Best Practices verhindern, dass Automatisierung zu unverständlichen „Auto-Graphs“ ohne Nutzen wird.

Table of Contents

Warum automatisierte Diagramme die Dokumentation deutlich verbessern

Automatisierung ersetzt nicht Denken, aber sie eliminiert repetitive Arbeit. Wenn Topologien, Segmentlisten oder Standortübersichten aus Daten generiert werden, entstehen drei Vorteile, die man im Betrieb sofort merkt: Erstens sinkt die Drift, weil Diagramme nicht mehr separat gepflegt werden müssen. Zweitens steigt die Nachvollziehbarkeit, weil Änderungen in der Datenquelle (z. B. NetBox) und die daraus erzeugten Diagramme zusammengehören. Drittens wird Dokumentation skalierbar: Auch bei vielen Standorten und Geräten bleiben Diagramme beherrschbar, weil die Generierung filterbar ist (Site, Role, Tag, VRF).

Aktualität: Diagramme folgen der Quelle der Wahrheit, statt „ein Snapshot von gestern“ zu sein.
Standardisierung: Layout, Legenden und Labels können zentral definiert werden.
Fehlerreduktion: weniger Copy/Paste und weniger manuelle Zeichenfehler.
Wiederverwendbarkeit: aus denselben Daten lassen sich unterschiedliche Views generieren (Incident View, Audit View, Standort View).

Voraussetzung: NetBox als verlässliche Datenquelle etablieren

Automatisierte Diagramme sind nur so gut wie die Daten, aus denen sie entstehen. Deshalb ist NetBox nicht „nur ein Tool“, sondern eine Arbeitsweise: Geräte, Interfaces, Kabelverbindungen, VLANs und Prefixe müssen konsequent gepflegt werden. Besonders wichtig: Uplinks und Backbone-Verbindungen sollten als Kabelverbindungen modelliert sein, weil viele Diagramm-Generatoren genau diese Beziehungen nutzen. NetBox stellt dafür eine REST API bereit, über die sich Geräte, Interfaces, IPAM und viele weitere Objekte abfragen lassen. Eine gute Orientierung bieten die NetBox-Projektseite netbox.dev sowie die API-Übersicht in der Dokumentation NetBox REST API.

Minimaldaten für Topologie-Generatoren: Devices, Interfaces, Cables, Device Roles, Sites/Locations.
Minimaldaten für Segmentdiagramme: VLANs, VRFs, Prefixe, Gateways/Reservierungen (mindestens als Metadaten).
Governance: Pflichtfelder wie Owner, Zweck, Status erhöhen die Aussagekraft der Diagramme.

Welche Diagrammtypen sich besonders gut aus Daten generieren lassen

Nicht jedes Diagramm eignet sich gleich gut für Vollautomatisierung. In der Praxis funktionieren automatisierte Diagramme am besten, wenn die Logik klar ist (Knoten und Kanten) und die Datenquelle stabil ist. Für andere Diagramme ist ein hybrider Ansatz besser: „automatisch generierter Kern“ plus manuelle Annotation.

Topologie-Maps: Geräte und Links (Core/Distribution/Access, Spine-Leaf, WAN-Hubs).
Standort-Views: pro Site/Building, gefiltert nach Device Role oder Tags.
Provider- und WAN-Übersichten: Edge-Geräte, Circuits/Terminations (falls in NetBox gepflegt).
Segment-Übersichten: VLANs, VRFs, Prefixe und Gateways (als Tabellen/Graphen).
Incident Views: reduzierte Topologie für schnelle Orientierung (nur kritische Links und Kontrollpunkte).

Tool-Kategorien: Von „Diagramm als Code“ bis zu visuellen Exports

Im Kern gibt es zwei Wege: Sie erzeugen Diagramme als Code (textbasiert, diffbar, ideal für Git und CI) oder Sie erzeugen fertige Grafiken/Dateien (PNG/SVG/draw.io). Beide Wege sind legitim – entscheidend ist, wofür das Diagramm genutzt wird. Für dauerhafte, versionierte Dokumentation sind textbasierte Formate oft überlegen; für schnelle Kommunikation im Incident sind PNG/SVG praktisch.

Diagramm als Code

Mermaid: leichtgewichtig, gut für Flowcharts und einfache Topologien (mermaid.js.org).
PlantUML: sehr flexibel, gut für komplexere Darstellungen (plantuml.com).
Graphviz: DOT-Sprache, stark für Graphen und Layout-Algorithmen (graphviz.org).

Grafik-/Datei-Export

draw.io/diagrams.net: verbreitetes Diagrammtool; ideal, wenn Teams visuell nachbearbeiten möchten (diagrams.net).
PNG/SVG-Render: für Wikis, PDFs oder schnelle Incident-Kommunikation.

Praxisweg 1: Topologie direkt in NetBox visualisieren

Für viele Teams ist der schnellste Einstieg nicht ein eigenes Skript, sondern ein bewährtes Plugin, das Topologieansichten aus NetBox-Verkabelung erzeugt. Ein verbreitetes Beispiel ist „NetBox Topology Views“: Es generiert Topologieansichten basierend auf den in NetBox gepflegten Kabeln, bietet Filter (z. B. nach Site, Tag, Device Role) und kann Exporte (u. a. für draw.io/diagrams.net) liefern. Projekt und Anleitung finden Sie unter netbox-topology-views. Das ist besonders praktisch, wenn Sie schnell sichtbaren Nutzen brauchen, ohne sofort eine eigene Pipeline zu bauen.

Vorteil: schneller Nutzen, geringe Implementierungsarbeit.
Voraussetzung: Verkabelung (Cables) muss konsistent gepflegt sein.
Praxisnutzen: filterbare Views pro Standort oder Rolle, ideal für Betrieb und Incident Response.

Praxisweg 2: Diagramme aus NetBox API generieren

Wenn Sie mehr Kontrolle über Layout, Labels, Legenden und Outputs benötigen, ist ein eigener Generator sinnvoll. Der grundlegende Ablauf ist immer ähnlich: (1) Daten aus NetBox API abfragen, (2) in ein internes Modell überführen (Nodes/Edges, Attribute), (3) in ein Zielformat rendern (Mermaid/PlantUML/DOT) oder als Bild exportieren. Die NetBox API ist dafür ideal, weil sie sauber strukturierte Objekte liefert. Ein Einstiegspunkt ist die NetBox API-Übersicht REST API Overview, die auch auf die interaktive Swagger-UI hinweist, die in einer laufenden NetBox-Instanz verfügbar ist.

Ein bewährtes internes Datenmodell

Node: Device (Hostname), optional ergänzt um Rolle, Site, Plattform, Management-IP.
Edge: Cable/Link zwischen zwei Interfaces, optional ergänzt um Link-Typ, LAG/Port-Channel, Bandbreite.
Filter: Site, Region, Tag, Device Role (z. B. nur core/dist, ohne access).
Label-Regeln: „weniger ist mehr“ – im Incident eher kurze Labels, im Audit eher detailreicher.

Praktische Filter, die Diagramme lesbar halten

Layer-Filter: nur Core/Distribution (Access ausblenden) für Übersichtlichkeit.
Site-Filter: pro Standort ein Diagramm, plus ein „WAN/Hub“-Gesamtbild.
Tag-Filter: z. B. „critical-path“, um nur essenzielle Links zu zeigen.
Link-Filter: nur Uplinks und Backbone, keine Endgeräteports.

Mermaid-Workflow: Schnell, git-freundlich, gut für Teams

Mermaid eignet sich besonders, wenn Sie Diagramme „als Code“ in Git verwalten wollen. Aus NetBox-Daten wird eine Mermaid-Datei erzeugt, die entweder direkt in Git gerendert wird (z. B. in GitLab/GitHub-Wikis) oder über CI als PNG/SVG exportiert wird. Für CLI-Rendering ist mermaid-cli verbreitet (mermaid-cli), wodurch sich Diagramme automatisiert bauen lassen.

Empfehlung: pro Diagramm eine eigene Datei (z. B. topology-ber-core.mmd).
Layout-Regel: feste Richtung (LR oder TB) je Diagrammtyp, damit Teams es wiedererkennen.
Legende als Code: standardisierte Legende/Notation als wiederverwendbarer Block.

PlantUML und Graphviz: Wenn Layout und Komplexität steigen

Sobald Diagramme größer werden oder Sie stärkeres Layout-Feintuning benötigen, sind PlantUML oder Graphviz oft die bessere Wahl. Graphviz (DOT) ist sehr stark bei Graph-Layouts und eignet sich hervorragend, um große Topologien algorithmisch anzuordnen. PlantUML bietet viele Diagrammtypen (auch UML), ist aber auch für Netzwerkübersichten nutzbar. Beide sind seit Jahren etabliert und lassen sich gut in CI integrieren. Einstiege: PlantUML und Graphviz.

Graphviz: ideal, wenn Sie „Nodes und Edges“ sauber aus Daten generieren.
PlantUML: gut, wenn Sie neben Topologien auch Prozessdiagramme (Runbooks) standardisieren wollen.
Praxis-Tipp: bei großen Graphen mit Clustern arbeiten (z. B. Cluster pro Site oder pro Layer).

draw.io/diagrams.net: Visuelle Nachbearbeitung ohne die Quelle zu verlieren

Manche Teams wollen Diagramme weiterhin visuell bearbeiten, aber nicht bei null anfangen. Hier ist ein Workflow sinnvoll, der automatisch eine Grundstruktur erzeugt und eine Bearbeitung erlaubt, ohne dass die Datenquelle verschwindet. Ein praktischer Ansatz: NetBox Topology Views kann XML für draw.io exportieren (netbox-topology-views). Damit bekommen Sie einen generierten Startpunkt, den Sie bei Bedarf mit zusätzlichen Notizen, Farbcodes oder Legenden ergänzen. Wichtig ist dann aber ein klarer Prozess: Was ist „Quelle der Wahrheit“ – NetBox oder das bearbeitete Diagramm?

Empfehlung: Bearbeitete draw.io-Dateien als „View“ behandeln, nicht als führende Datenbasis.
Versionierung: Diagrammdateien im Git verwalten, Änderungen per Pull Request reviewen.
Regel: Daten (Geräte/Links/IPAM) werden in NetBox gepflegt, Diagramm ist Darstellung.

CI/CD für Diagramme: Automatisch bauen, prüfen und veröffentlichen

Der größte Qualitätssprung entsteht, wenn Diagramme nicht lokal auf Laptops entstehen, sondern in einem zentralen Build-Prozess: NetBox liefert Daten, ein Generator erzeugt Diagrammcode oder Grafiken, CI prüft und veröffentlicht. So wird Dokumentation reproduzierbar. Typische Outputs sind: SVG/PNG für Wikis, Mermaid/PlantUML-Dateien für Git, oder eine statische Doku-Seite.

Pipeline-Schritt 1: NetBox API abfragen (Read-only Token, sicher verwaltet).
Pipeline-Schritt 2: Generator erzeugt Diagrammcode (Mermaid/DOT/PlantUML) pro Filter.
Pipeline-Schritt 3: Renderer erzeugt SVG/PNG (z. B. mit mermaid-cli).
Pipeline-Schritt 4: Publish (Git Pages, internes Wiki, Artefaktablage) + Versionsstand.
Pipeline-Schritt 5: Checks (leere Diagramme, kaputte Links, Mindestknotenanzahl) als Quality Gate.

Teamworkflow: Wer pflegt Daten, wer pflegt Diagramme?

Damit Automatisierung nachhaltig funktioniert, müssen Verantwortlichkeiten klar sein. In der Praxis bewährt sich eine Trennung: NetOps pflegt die Daten in NetBox (Devices, Interfaces, Cables, IPAM), während ein kleiner Kreis (oder eine Plattformrolle) die Generatorpipeline verantwortet. Diagrammänderungen passieren dann überwiegend über Datenänderungen. Nur selten wird die Diagramm-Logik selbst geändert (z. B. neue Filter, neue Label-Regeln).

Data Maintainer: pflegt NetBox-Objekte, sorgt für korrekte Kabelverbindungen und Metadaten.
Diagramm Maintainer: pflegt Generatorregeln, Templates, CI-Pipeline, Veröffentlichung.
Reviewer: prüft Änderungen an „kritischen Views“ (WAN/DMZ/Core) im Vier-Augen-Prinzip.

Best Practices für lesbare, automatisch erzeugte Diagramme

Automatisch erzeugte Diagramme können schnell „unlesbar“ werden, wenn sie zu viele Details enthalten. Der Schlüssel ist bewusstes Reduzieren: weniger Knoten, weniger Kanten, dafür klarer Kontext. Dazu gehören Layering, Filter, konsistente Farben (falls genutzt) und standardisierte Legenden. Besonders gut funktionieren mehrere kleine Views statt eines großen „Alles-auf-einem-Bild“-Plans.

Views statt Monsterdiagramm: pro Site, pro Layer, pro Domäne (WAN/DC/Campus).
Kritische Pfade taggen: z. B. „critical-path“ in NetBox, daraus Incident Views generieren.
Kanten beschriften sparsam: z. B. nur LAG/Port-Channel und Bandbreite, nicht jede Interface-ID.
Stabile Layoutregeln: gleiche Richtung (LR/TB), gleiche Clusterlogik, gleiche Symbolik.
Qualitätschecks: Warnung bei „0 Links“ oder „zu viele Links“ (Signal für fehlende Kabelpflege oder falsche Filter).

Sicherheit und Zugriff: Automatisierung ohne Geheimnisse

Diagrammautomatisierung braucht meist API-Zugriff auf NetBox. Dieser Zugriff sollte minimalprivilegiert sein (Read-only) und in einem Secret Store liegen – nicht in Skripten oder CI-Logs. Außerdem sollten Sie entscheiden, welche Diagramme intern breit geteilt werden dürfen. Perimeter- und Managementansichten sind oft sensibler als Campus-Übersichten. Ein Schichtenmodell ist sinnvoll: allgemeine Views breit, sensitive Views eingeschränkt.

Read-only Token: nur lesen, keine Schreibrechte über CI.
Secret Handling: Token in Secret Store, CI nutzt geschützte Variablen.
Publishing-Scopes: getrennte Bereiche für „Allgemein“ und „sensitiv“.
Keine Secrets im Diagramm: keine Passwörter, Keys oder internen Portalzugänge in Labels/Notizen.

Outbound-Links für Tools und Referenzen

Checkliste: Diagramme aus Daten generieren mit NetBox & Tools

NetBox ist als Quelle der Wahrheit etabliert: Devices, Interfaces und Cables sind für kritische Links gepflegt.
Es gibt klare Diagrammtypen und Views (Incident View, Standort View, WAN View), statt ein einziges Großdiagramm.
Filterregeln sind definiert (Site, Role, Tag, Layer), damit Diagramme lesbar bleiben.
Ein Toolweg ist gewählt: Plugin (schnell) oder API-Generator (maximale Kontrolle) – ohne zwei konkurrierende Wahrheiten.
Diagramm-Output ist standardisiert (Mermaid/PlantUML/DOT für Git, SVG/PNG für Kommunikation, optional draw.io für visuelle Views).
CI/CD baut Diagramme reproduzierbar und prüft Qualität (leere Ergebnisse, Renderfehler, Mindestfelder).
Teamrollen sind klar: Data Maintainer pflegt NetBox, Diagramm Maintainer pflegt Generator und Pipeline.
Sicherheit ist berücksichtigt: Read-only API-Token, Secret Store, keine Geheimnisse in Labels oder Repos.
Eine Review-Routine existiert: fehlende Kabelverbindungen, verwaiste Devices und unplausible Diagramme werden regelmäßig bereinigt.
Dokumentation bleibt nutzbar: Legenden, Naming Standards und stabile Layoutregeln sorgen dafür, dass „automatisch“ nicht „unverständlich“ bedeutet.

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.