NetBox als DCIM-Startpaket für den Mittelstand

Wer im Mittelstand eine Netzwerk-Dokumentation pflegt, kennt das Bild: eine Excel-Tapete mit IP-Adressen, ein Confluence-Artikel mit Rack-Skizzen, eine Visio-Datei aus dem Jahr, in dem der letzte Netzwerker aufgehört hat, und dazu ein paar Screenshots aus der Switch-GUI. Das funktioniert — bis der erste Ausfall kommt, ein Umzug ansteht oder der Wirtschaftsprüfer nach einer belastbaren Asset-Liste fragt. Ab dieser Grenze lohnt sich ein echtes DCIM- und IPAM-Werkzeug, und NetBox ist dafür seit Jahren der pragmatische Standard.

NetBox 4.3 ist Open-Source, in Python/Django geschrieben und deckt genau die drei Bereiche ab, die Excel besonders schmerzhaft macht: Rack- und Standortverwaltung (DCIM), IP-Adressverwaltung (IPAM) und die Modellierung von Verbindungen zwischen Geräten, Providern und virtuellen Ressourcen. Wir setzen NetBox seit mehreren Jahren bei Kunden mit 10 bis 300 Endgeräten ein und zeigen in diesem Artikel, wie ein realistisches Startpaket aussieht — vom leeren Server bis zur ersten Ansible-Integration.

Wann NetBox der richtige Einstieg ist

NetBox ist nicht das Werkzeug für alles. Es ist eine “Source of Truth” für den Soll-Zustand Ihrer Infrastruktur, kein Monitoring, kein Ticketsystem und keine vollständige CMDB nach ITIL-Lehrbuch. Genau deshalb funktioniert es im Mittelstand so gut: Es zwingt zu keinem Prozess-Framework, sondern liefert ein sauberes Datenmodell und eine API, an der andere Werkzeuge andocken.

Sinnvoll wird der Einstieg typischerweise ab einer der folgenden Situationen:

• Sie betreiben mehr als ein Rack oder mehr als einen Standort und die IP-Planung ist bereits einmal kollidiert.
• Sie automatisieren Konfigurationen mit Ansible, Terraform oder Nornir und brauchen eine strukturierte Datenquelle.
• Wirtschaftsprüfung, TISAX oder eine NIS2-Betroffenheit verlangen eine belastbare Asset-Inventur.
• Ihr Team wächst und das Wissen “wo hängt eigentlich der Drucker im zweiten OG” existiert nur im Kopf einer Person.

Wenn nichts davon zutrifft, reicht ein gepflegtes Wiki. Ab dem ersten Punkt lohnt sich der halbe Tag Setup fast immer.

Das Datenmodell in vier Ebenen

Bevor man die erste VM startet, ist es hilfreich, das NetBox-Datenmodell zu verstehen. Es ist strikt hierarchisch und genau darin liegt sein Wert: Sie können keine “IP-Adresse ohne Präfix” oder “Rack ohne Standort” anlegen. Diese Disziplin verhindert langfristig genau die Datenmüllhalden, die man aus Excel kennt.

Ebene	Objekte	Typischer Inhalt im Mittelstand
Standort	Region, Site, Location	HQ Neuburg, Zweigstelle München, Serverraum EG
Physik	Rack, Device, Module, Cable	42HE-Rack, Switch, Server, Patchkabel
Logik	VLAN, VRF, Prefix, IP-Adresse	VLAN 20 Client, 10.20.0.0/16, 10.20.1.5/24
Virtualisierung	Cluster, VM, VMinterface	Proxmox-Cluster, VM fileserver01, eth0

Zusätzlich gibt es die Ebene “Circuits” für WAN-Verbindungen (Telekom-Anschluss, Standleitung, SIP-Trunk) und “Tenancy” für Mandantentrennung, falls Sie mehrere Firmen oder Kunden abbilden. Für den Start reichen die ersten vier Ebenen aus.

Setup in vier Stunden

Wir installieren NetBox in nahezu jedem Kundenprojekt als Docker-Compose-Stack auf einer kleinen VM — typischerweise zwei vCPUs, 4 GB RAM und 40 GB Storage. Das reicht bis in den vierstelligen Objektbereich problemlos. Der offizielle netbox-docker-Stack ist gut gepflegt und wir konfigurieren ihn wie folgt:

# docker-compose.override.yml
services:
  netbox:
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      SUPERUSER_NAME: admin
      SUPERUSER_EMAIL: it@example.de
      ALLOWED_HOSTS: "netbox.intern.example.de"
      TIME_ZONE: "Europe/Berlin"
      REMOTE_AUTH_ENABLED: "true"
      REMOTE_AUTH_HEADER: "HTTP_X_REMOTE_USER"

Vor die NetBox-VM setzen wir einen Nginx-Reverse-Proxy mit LDAP- oder OIDC-Authentifizierung (bei Kunden mit Entra ID typischerweise via oauth2-proxy), sodass die Anmeldung an der bestehenden Identität hängt. Ein regelmässiges PostgreSQL-Backup, eingebunden in die bestehende Backup-Strategie, rundet die Basis-Installation ab.

Der eigentliche Zeitfresser ist nicht die Installation, sondern die Erstbefüllung. Ein realistischer Vier-Stunden-Plan sieht so aus:

• 30 Minuten Docker-Stack aufsetzen, Reverse-Proxy und Login testen.
• 30 Minuten Custom Fields definieren (Inventarnummer, Beschaffungsdatum, Kostenstelle).
• 60 Minuten Standorte, Racks und Rack-Rollen anlegen.
• 90 Minuten Geräte-Typen aus der Community-Library importieren und Bestandsgeräte einpflegen.
• 30 Minuten IP-Präfixe, VLANs und die wichtigsten Circuits erfassen.

Die Device-Type-Library auf GitHub enthält fertige YAML-Definitionen für die gängigen Modelle von Dell, HPE, Cisco, MikroTik, Ubiquiti und weiteren Herstellern — das spart pro Geräteklasse rund 15 Minuten Pflegeaufwand.

IPAM: Vom Excel-Chaos zur sauberen Hierarchie

Der schnellste Aha-Effekt entsteht meist im IPAM-Modul. NetBox modelliert IP-Adressen strikt in Aggregaten, Präfixen und Adressen, mit optionaler VRF-Zuordnung. Ein typisches Setup für einen Mittelständler mit zwei Standorten sieht so aus:

Aggregate: 10.0.0.0/8 (RFC1918)
├── Prefix: 10.10.0.0/16    (Standort HQ)
│   ├── Prefix: 10.10.10.0/24  VLAN 10 Management
│   ├── Prefix: 10.10.20.0/24  VLAN 20 Client
│   └── Prefix: 10.10.30.0/24  VLAN 30 Server
└── Prefix: 10.20.0.0/16    (Standort Zweigstelle)
    ├── Prefix: 10.20.10.0/24  VLAN 10 Management
    └── Prefix: 10.20.20.0/24  VLAN 20 Client

Jedes Präfix hat einen Status (aktiv, reserviert, deprecated), eine Auslastungsanzeige und eine Verknüpfung zu den vergebenen IP-Adressen. Die “Available IPs”-Ansicht zeigt in Sekunden, welche Adresse als nächstes frei ist — ohne dass jemand eine Excel-Zeile aktualisieren muss. In Verbindung mit einer sauberen Firewall-Dokumentation auf Basis von OPNsense verschwinden die klassischen “haben wir die 10.10.30.42 schon vergeben”-Diskussionen komplett.

Integration mit Ansible und Prometheus

Der eigentliche Hebel entsteht, sobald NetBox nicht mehr nur Dokumentation ist, sondern die Quelle für andere Systeme wird. Zwei Integrationen liefern in unserer Erfahrung den schnellsten Return:

Ansible Dynamic Inventory über die netbox.netbox.nb_inventory-Plugin-Collection: Sie definieren einmalig, welche NetBox-Filter (z. B. device_roles=proxmox-host) welche Ansible-Gruppen erzeugen, und Ansible zieht die aktuelle Geräteliste bei jedem Playbook-Lauf frisch aus der API. Neu aufgenommene Server tauchen automatisch im nächsten Konfigurationslauf auf — ohne händisch gepflegte hosts.ini.

# inventory.yml
plugin: netbox.netbox.nb_inventory
api_endpoint: https://netbox.intern.example.de
token: !vault | ...
group_by:
  - device_roles
  - sites
  - tags

Prometheus Service Discovery über den netbox-agent-Exporter oder direkt via http_sd_config: Prometheus fragt NetBox nach allen Geräten mit dem Tag monitoring und generiert daraus automatisch die Scrape-Ziele. Ein neu eingebuchter Switch wird sofort mit-überwacht, sobald er in NetBox das entsprechende Tag trägt. Für unsere Linux-Kunden mit gemischten Bare-Metal- und Proxmox-Umgebungen ist das die bequemste Variante, um Monitoring-Blindflüge zu vermeiden.

Wann NetBox an seine Grenzen kommt

NetBox ist bewusst schlank. Es ist keine vollwertige CMDB und ersetzt weder ein ITSM-Tool noch ein Software-Asset-Management. Wir empfehlen einen Umstieg oder eine Ergänzung, sobald:

• Sie Änderungen genehmigungspflichtig abbilden wollen (Change Advisory Board, Approval-Workflows). NetBox kennt zwar “Change Logs”, aber keine echten Workflow-Engines.
• Sie Software-Lizenzen, Wartungsverträge und finanzielle Abschreibungen tracken müssen — das gehört in ein ITSM- oder ERP-System.
• Sie Ticket-Prozesse (Incident, Problem, Request) sauber abbilden möchten. Hier passt eher Zammad oder OTRS, die per API mit NetBox koppeln.
• Sie Compliance-Nachweise für NIS2 oder ISO 27001 auf Assetebene brauchen, die über Custom Fields hinausgehen.

In diesen Fällen bleibt NetBox oft als “Data Layer” bestehen und wird per Webhook oder API an das übergeordnete System angebunden — ein Muster, das wir in TrueNAS-lastigen Storage-Umgebungen mit paralleler NAS-Doku und in grösseren Proxmox-Umgebungen mit CI/CD-Anbindung regelmässig fahren.

Fazit

NetBox ist kein Framework, das Wochen an Prozess-Design braucht, sondern ein pragmatisches Werkzeug, das an einem Vormittag steht und ab dem ersten Tag Ordnung schafft. Der grösste Fehler beim Einstieg ist der Versuch, sofort jedes denkbare Custom Field zu modellieren. Fangen Sie mit dem Standardmodell an, füllen Sie es sauber, und ergänzen Sie Felder erst dann, wenn sie mehr als einmal fehlen. Der zweite typische Fehler ist die fehlende API-Anbindung: Wer NetBox nur als hübsche Doku betreibt, verpasst 80 Prozent des Werts.

DATAZONE unterstützt Sie beim Aufbau einer sauberen Netzwerk- und Asset-Dokumentation — vom initialen NetBox-Setup über die Migration Ihrer Excel-Bestände bis zur Anbindung an Ansible, Prometheus und Ihre bestehenden Proxmox- oder TrueNAS-Umgebungen. Sprechen Sie uns an, wenn Sie den Excel-Wildwuchs beenden möchten.