Eine gepflegte Netzwerkdokumentation mit IP-Adressplan (IPAM, IP Address Management) verhindert IP-Konflikte und beschleunigt Fehlersuche und Übergabe. Diese Anleitung führt Sie vom Mindestumfang über ein Subnetz-Schema bis zum selbst betriebenen IPAM-Tool (phpIPAM oder NetBox per Docker) und einem Pflegeprozess.

Voraussetzungen

Klären Sie vorab:

Überblick über Ihr Netz: vorhandene Subnetze, VLANs, zentrale Geräte (Router, Switches, Server, Firewalls) und Standorte.
Wer künftig für die Pflege zuständig ist. Dokumentation ohne klare Verantwortung veraltet schnell.
Für ein selbst betriebenes IPAM-Tool einen Docker-Host (x86_64 oder ARM64). phpIPAM läuft mit 1 Kern und 1 GB RAM, NetBox mit PostgreSQL und Redis braucht 2 Kerne und 4 GB RAM. Für NetBox: Docker >= 20.10.10, containerd >= 1.5.6 und docker-compose >= 1.28.0. Prüfen Sie das mit docker --version und docker compose version.
Grundkenntnisse in Subnetting/CIDR, DHCP und VLANs (Anleitungen unten verlinkt).

Schritt 1: Warum dokumentieren und was es kostet, wenn Sie es nicht tun

Dokumentation zahlt sich aus bei:

IP-Konflikten: Ohne Plan werden Adressen doppelt vergeben.
Nachvollziehbarkeit: Die Änderungshistorie zeigt, wer wann was geändert hat.
Fehlersuche: Topologie, IPs und Zuständigkeiten liegen sofort vor.
Übergabe: Das Netzwissen hängt nicht an einer Person.

Kernregel: Jede Änderung wird sofort dokumentiert, als Teil des Change-Managements.

Verifizieren: Die verantwortliche Person ist schriftlich benannt.

Verifizieren: Sie haben schriftlich festgelegt, welche dieser Ziele für Ihr Netz gelten und wer die Dokumentation verantwortet.

Schritt 2: Mindestumfang der Netzwerkdokumentation festlegen

Eine vollständige Netzwerkdokumentation besteht aus sieben Bausteinen. Die Tabelle dient als Checkliste:

#	Baustein	Inhalt
1	Netzplan / Topologie	Getrennt physisch (Verkabelung, Patchpanel, Räume) und logisch (L3/Routing, Subnetze, Gateways)
2	IP-/Subnetzplan	Alle Subnetze mit Zweck, CIDR, Gateway, statischen Bereichen, DHCP-Pools und Reservierungen
3	VLAN-Liste	VLAN-ID, Name/Zweck, zugehöriges Subnetz, getaggte/ungetaggte Ports
4	Geräte-/Port-Inventar	Hersteller, Modell, Seriennummer, Standort, Firmware, Port-Belegung
5	DNS-/Namenskonzept	Namensschema für Hosts, Zonen, interne/externe Auflösung
6	Zuständigkeiten	Verantwortliche, Kontakte, Eskalationswege, Wartungsverträge
7	Änderungshistorie	Wer, wann, was, warum – verknüpft mit dem Change-Management

Trennen Sie beim Netzplan die physische von der logischen Sicht. Die physische Sicht zeigt Kabelwege von Patchpanel zu Switch-Port, die logische Subnetze, Routing und Gateways.

Verifizieren: Für jeden der sieben Bausteine gibt es ein Dokument oder einen Bereich im Tool, auch wenn er noch unvollständig ist.

Schritt 3: Datenfelder für IP-Plan und Inventar definieren

Jeder Eintrag im IP-Plan braucht dieselben Felder.

Mindestfelder je IP-Eintrag:

IP-Adresse | Subnetzmaske/CIDR | Hostname | Geraet/Funktion |
MAC-Adresse | VLAN | Standort | Verantwortlicher | Status

Status-Werte: vergeben | frei | reserviert

Zusätzliche Felder für das Geräte-/Port-Inventar:

Hersteller | Modell | Seriennummer | Standort |
Kaufdatum | Garantie/Support-Ende | Firmware-Version

Beispiel einer ausgefüllten Tabelle:

IP             CIDR   Hostname        Funktion        VLAN  Status
10.20.10.1     /24    gw-core-01      Gateway/Router  10    vergeben
10.20.10.10    /24    srv-dc-01       Domaincontroller 10   vergeben
10.20.10.11    /24    srv-file-01     Fileserver      10    vergeben
10.20.10.20    /24    -               Reserve Server  10    frei
10.20.10.50    /24    prn-og2-01      Drucker         10    reserviert
10.20.10.100   /24    DHCP-Pool-Start Clients         10    DHCP
10.20.10.200   /24    DHCP-Pool-Ende  Clients         10    DHCP

Verifizieren: Jede Zeile Ihres IP-Plans enthält alle Mindestfelder, und jede Status-Spalte nutzt nur die festgelegten Werte.

Schritt 4: Das Subnetz-Schema planen

Planen Sie die CIDR-Aufteilung vor dem Ausrollen. Zur Verfügung stehen die privaten Bereiche nach RFC 1918:

RFC-1918-Bereich	Größe	Typischer Einsatz
10.0.0.0/8	> 16 Mio. Adressen	Größter Block, Default für größere/Enterprise-Netze, viel Platz zum Strukturieren
172.16.0.0/12	~1 Mio. Adressen	Mittelgroße Netze, oft für Labor/Management getrennt
192.168.0.0/16	65.536 Adressen	Kleine Netze, Heim/kleines KMU – Achtung: häufig genutzt, Konfliktgefahr bei VPN

Best Practices für das Schema:

Lassen Sie Lücken für Wachstum, vergeben Sie Subnetze nicht lückenlos hintereinander.
Gruppieren Sie Hosts mit ähnlichem Bedarf (z. B. Server, Clients, VoIP, Management, Gäste) in eigene Subnetze.
Bevorzugen Sie in Produktion /24 oder größer, das hält die Verwaltung einfach.
Vergeben Sie Adressen global eindeutig. Wenn später zwei Standorte per VPN gekoppelt werden, dürfen sich die Bereiche nicht überschneiden, sonst sind NAT oder Routing-Konflikte die Folge.

Ein sprechendes Schema spiegelt z. B. die VLAN-ID im dritten Oktett:

Standort Hauptsitz: 10.20.0.0/16  (Wachstumsblock)

VLAN 10  Server        10.20.10.0/24
VLAN 20  Clients       10.20.20.0/24
VLAN 30  VoIP          10.20.30.0/24
VLAN 40  Management    10.20.40.0/24
VLAN 90  Gaeste (DMZ)  10.20.90.0/24

Standort Filiale:  10.30.0.0/16  (eigener Block, keine Ueberschneidung)

Die genaue CIDR-Berechnung (Hostzahl je Maske, Netz-/Broadcast-Adresse) zeigt der verlinkte Subnetting-Artikel unten.

Verifizieren: Kein Subnetz Ihres Schemas überschneidet sich mit einem anderen Standort oder einer VPN-Gegenstelle; prüfen Sie das in der Tabelle oder später im IPAM-Tool.

Schritt 5: Statische Bereiche, DHCP-Pools und Reservierungen trennen

Überlappen statischer Bereich und DHCP-Pool, sind IP-Konflikte sicher. Teilen Sie jedes /24 klar auf:

Bereich	Beispiel (in 10.20.10.0/24)	Verwendung
Statischer Bereich	.1 bis .99	Gateway, Server, Drucker, feste Infrastruktur – manuell vergeben
DHCP-Pool	.100 bis .200	Clients/Endgeräte – automatisch vom DHCP-Server
Reservierungen	.201 bis .254	Feste Client-IPs per DHCP-Reservation (an MAC gebunden)

Eine statische IP wird direkt am Gerät eingetragen (Server, Gateway) und funktioniert ohne DHCP-Server. Eine DHCP-Reservierung liefert dem Gerät per MAC-Bindung immer dieselbe Adresse und lässt sich zentral verwalten. Die Konfiguration zeigt die DHCP-Anleitung unten.

Verifizieren: Der DHCP-Bereich im DHCP-Server entspricht exakt dem Pool im Plan, und keine statisch vergebene Adresse liegt darin.

Schritt 6: Tool-Wahl: NetBox oder phpIPAM

Für die digitale Quelle der Wahrheit gibt es zwei verbreitete Open-Source-Werkzeuge zum Selbstbetrieb:

Kriterium	phpIPAM	NetBox
Lizenz	frei / Open Source	Open Source (Apache 2.0)
Schwerpunkt	IP-/Subnetz-/VLAN-Management	Vollständige Source of Truth (Netz, Geräte, Racks, Kabel, API)
Gewicht	Leichtgewichtig, schnell startklar	Schwergewichtig, mehr Datenmodell- und Pflegeaufwand
Stack	Web + Cron + MariaDB	NetBox + PostgreSQL + Redis
Standard-Webport	80	8000
Ideal für	KMU, schnelle Inbetriebnahme, reines IPAM	Automatisierung, Doku-Tiefe, API-getriebene Umgebungen

phpIPAM passt, wenn Sie vor allem IPs, Subnetze und VLANs verwalten und schnell starten wollen. NetBox passt, wenn Sie eine vollständige Netz-, Geräte-, Rack- und Kabeldokumentation mit API und Automatisierung brauchen und den höheren Pflegeaufwand akzeptieren.

Verifizieren: Die Entscheidung für genau ein Werkzeug ist getroffen und dokumentiert.

Schritt 7: phpIPAM per Docker einrichten

Der offizielle Docker-Stack von phpIPAM besteht aus dem Web-Container, genau einer Cron-Instanz (für Discovery/Ping) und einer MariaDB.

Das Repository enthält keine fertige Compose-Datei. Speichern Sie das Beispiel aus der README in einem Projektordner als compose.yaml und ersetzen Sie die Beispielpasswörter:

services:
  phpipam-web:
    image: phpipam/phpipam-www:latest
    ports:
      - "80:80"
    environment:
      - TZ=Europe/Berlin
      - IPAM_DATABASE_HOST=phpipam-mariadb
      - IPAM_DATABASE_PASS=my_secret_phpipam_pass
      - IPAM_DATABASE_WEBHOST=%
    restart: unless-stopped
    volumes:
      - phpipam-logo:/phpipam/css/images/logo
      - phpipam-ca:/usr/local/share/ca-certificates:ro
    depends_on:
      - phpipam-mariadb
    cap_add:
      - NET_ADMIN
      - NET_RAW

  phpipam-cron:
    image: phpipam/phpipam-cron:latest
    environment:
      - TZ=Europe/Berlin
      - IPAM_DATABASE_HOST=phpipam-mariadb
      - IPAM_DATABASE_PASS=my_secret_phpipam_pass
      - SCAN_INTERVAL=1h
    restart: unless-stopped
    volumes:
      - phpipam-ca:/usr/local/share/ca-certificates:ro
    depends_on:
      - phpipam-mariadb
    cap_add:
      - NET_ADMIN
      - NET_RAW

  phpipam-mariadb:
    image: mariadb:latest
    environment:
      - MYSQL_ROOT_PASSWORD=my_secret_mysql_root_pass
    restart: unless-stopped
    volumes:
      - phpipam-db-data:/var/lib/mysql

volumes:
  phpipam-db-data:
  phpipam-logo:
  phpipam-ca:

docker compose -p phpipam up -d

Schreiben Sie latest für den Produktivbetrieb auf feste Versionen fest.

Die Container brauchen die Capabilities NET_ADMIN und NET_RAW, sonst funktionieren automatisches Ping-Scanning, Host-Status und SNMP nicht. Sensible Werte (DB-Passwort) können über *_FILE-Variablen aus Docker Secrets geladen werden. Ohne eigene Werte gelten diese Standardwerte:

DB-User:     phpipam
DB-Passwort: phpipamadmin
DB-Name:     phpipam

Erst-Setup im Browser:

Rufen Sie http://<host>/ auf und folgen Sie dem Setup: Datenbank installieren lassen, dann Admin-Passwort setzen.
Melden Sie sich mit dem Standard-Login an: Benutzer Admin, Passwort ipamadmin.
phpIPAM erzwingt direkt nach dem Login den Wechsel des Default-Passworts. Wählen Sie ein starkes Passwort.
Legen Sie unter Administration → Sections eine Section (z. B. Standort) an, darunter Ihre Subnets. phpIPAM zeigt freien Platz und eine Subnetz-Darstellung automatisch an.

phpIPAM bietet außerdem Subnetz-Scans, VLAN-/VRF-/Rack-Verwaltung, LDAP-Anbindung, REST-API sowie CSV-Import für den Start.

Verifizieren: docker compose -p phpipam ps zeigt drei laufende Container, die Anmeldung als Admin mit dem neuen Passwort gelingt, und das angelegte Subnetz erscheint mit Auslastungsanzeige.

Schritt 8: NetBox per Docker einrichten

Der Docker-Stack von NetBox umfasst NetBox, PostgreSQL und Redis.

# Offizielles Docker-Repo (Branch release) holen
git clone -b release https://github.com/netbox-community/netbox-docker.git
cd netbox-docker

# Override-Datei anlegen: hier Port 8000 und optional SUPERUSER_*-Variablen setzen
cp docker-compose.override.yml.example docker-compose.override.yml

# Images ziehen und Stack starten
docker compose pull
docker compose up -d
# Web-UI danach unter http://<host>:8000/

Legen Sie den Admin-Benutzer entweder über die SUPERUSER_*-Variablen in der docker-compose.override.yml automatisch an oder interaktiv:

docker compose exec netbox /opt/netbox/netbox/manage.py createsuperuser

Produktion: Verwenden Sie versionierte Tags (vX.Y.Z-a.b.c), nicht latest oder snapshot, sonst drohen unkontrollierte Upgrades und Datenmodell-Brüche.

Das IPAM-Objektmodell von NetBox ist hierarchisch:

Aggregates (pro RIR, grosse Bloecke)
   -> Prefixes (mit Status + Rolle, auch Container-Prefixe)
        -> IP Ranges
             -> IP Addresses

Ergaenzend:
  VRF (auch ueberlappende Adressraeume)
  VLANs + VLAN Groups
  AS Numbers, Services

Die Auslastung berechnet NetBox je Prefix automatisch. IP-Adressen werden Interfaces zugewiesen, nicht direkt Geräten.

Verifizieren: docker compose ps meldet netbox, postgres und redis als healthy bzw. running, und die Anmeldung unter http://<host>:8000/ mit dem Superuser gelingt.

Schritt 9: Pflegeprozess und Disziplin etablieren

Mit diesen Regeln bleibt die Dokumentation verlässlich:

Eine Source of Truth: Entscheiden Sie sich für das IPAM-Tool oder die Tabelle – nie beides parallel pflegen, sonst driften die Daten auseinander.
Change-Management: Jede Änderung wird im Change-Prozess dokumentiert, keine Vergabe ohne Eintrag.
Regelmäßiger Abgleich: Lassen Sie phpIPAM den Ist-Stand scannen (Discovery/Ping) und gleichen Sie ihn gegen die Dokumentation ab; NetBox braucht dafür ein Plugin oder ein Skript.
Versionierung und Backup: Sichern Sie die Dokumentation bzw. die IPAM-Datenbank regelmäßig.

Verifizieren: Ein Termin für den ersten Abgleich steht im Kalender, und ein Backup der IPAM-Datenbank ist einmal zurückgespielt worden.

Troubleshooting / Typische Fehler

Dokumentation veraltet: Pflege als festen Teil des Änderungsprozesses verankern.
Zwei parallele Wahrheiten: Tabelle und IPAM-Tool driften auseinander. Eine Quelle festlegen.
Überschneidende RFC-1918-Bereiche: Bei VPN-Kopplung kollidieren z. B. beidseitig 192.168.1.0/24. Adressen global eindeutig vergeben.
DHCP-Pool und statischer Bereich überlappen: Bereiche im Plan und im DHCP-Server trennen (Schritt 5).
NetBox mit latest/snapshot: unkontrollierte Upgrades. Versionierte Tags nutzen.
NetBox startet nicht: Docker älter als 20.10.10 oder Compose älter als 1.28.0. Docker aktualisieren.
NetBox-UI nicht erreichbar: docker-compose.override.yml fehlt oder Port 8000 ist nicht freigegeben.
phpIPAM Default-Login nicht geändert: Admin/ipamadmin ist ein kritisches Sicherheitsrisiko; starkes Passwort setzen (Schritt 7).
phpIPAM ohne NET_ADMIN/NET_RAW: Ping-Scan, Host-Status und SNMP fallen aus. Capabilities ergänzen.
Mehrere phpipam-cron-Instanzen: doppelte Scan-Jobs. Genau eine Instanz betreiben.

Häufige Fragen

Excel oder ein IPAM-Tool – was ist besser?

Für kleine, stabile Netze reicht eine Tabelle mit festem Spaltenschema. Bei mehreren Subnetzen, VLANs und Bearbeitern zeigt ein IPAM-Tool freien Platz, scannt den Ist-Stand und verhindert Doppelvergaben.

Welchen RFC-1918-Bereich soll ich wählen?

Für wachsende Netze 10.0.0.0/8 wegen des Platzes. 192.168.0.0/16 kollidiert bei VPNs oft mit Gegenstellen. Vergeben Sie Bereiche global eindeutig (Schritt 4).

Was ist der Unterschied zwischen statischer IP und DHCP-Reservierung?

Eine statische IP wird am Gerät eingetragen und funktioniert ohne DHCP-Server; eine Reservierung liefert per MAC-Bindung immer dieselbe Adresse vom DHCP-Server. Details in Schritt 5.

Reicht phpIPAM, oder brauche ich NetBox?

Für IPs, Subnetze und VLANs reicht phpIPAM. NetBox lohnt sich für eine vollständige Source of Truth mit Geräte-, Rack- und Kabeldoku sowie API, bei höherem Pflegeaufwand (Schritt 6).

Wie halte ich die Doku langfristig aktuell?

Binden Sie die Pflege an das Change-Management, legen Sie eine zuständige Person fest und gleichen Sie den gescannten Ist-Stand regelmäßig ab (Schritt 9).

Muss ich physische und logische Topologie wirklich trennen?

Ja, beide verfolgen unterschiedliche Zwecke und werden in einem Diagramm unlesbar (Schritt 2).

Fazit

Eine belastbare Netzwerkdokumentation entsteht aus Struktur und Disziplin, nicht aus einem Werkzeug. Legen Sie den Mindestumfang fest, planen Sie Subnetze global eindeutig und teilen Sie jedes Netz in statischen Bereich, DHCP-Pool und Reservierungen. phpIPAM (schlank) oder NetBox (umfassend, mit API) dienen als Quelle der Wahrheit. Den Ausschlag gibt der Pflegeprozess mit klaren Zuständigkeiten.

Weiterführende Anleitungen und Quellen

Subnetting und CIDR verständlich erklärt – für die konkrete Berechnung Ihres Subnetz-Schemas (Hostzahl, Maske, Netz-/Broadcast-Adresse).
DHCP- und DNS-Rolle auf Windows Server konfigurieren – um DHCP-Pools, Reservierungen und das DNS-/Namenskonzept umzusetzen.
VLANs verstehen und Managed Switch einrichten – für die VLAN-IDs in Ihrer VLAN-Liste und die Subnetz-Zuordnung.
Weitere Anleitungen in der Kategorie Netzwerk

Quellen: netbox-community/netbox-docker (offizielles Docker-Repo, Quickstart/Voraussetzungen/Tags), NetBox Documentation – IP Address Management (Objektmodell), phpipam-docker (offizielles Docker-Repo, Compose/Capabilities/ENV-Defaults) sowie phpIPAM.net (Features, Lizenz, Setup/Default-Login).