Eine saubere Netzwerkdokumentation und ein IP-Adressplan (IPAM) sind die Lebensversicherung deines Netzes: Sie verhindern IP-Konflikte und Wildwuchs, machen jede Änderung nachvollziehbar und ermöglichen im Notfall eine schnelle Fehlersuche oder eine saubere Übergabe an Dritte. In dieser Anleitung baust du die Doku systematisch auf – vom Mindestumfang über ein durchdachtes Subnetz-Schema bis zum self-hosted IPAM-Tool (NetBox oder phpIPAM per Docker) – inklusive fertiger Vorlagen, Vergleichstabellen und einem Pflegeprozess, der die Doku dauerhaft aktuell hält.

Voraussetzungen

Bevor du loslegst, sollten diese Punkte geklärt sein:

Du hast einen Überblick über dein Netz: vorhandene Subnetze, VLANs, zentrale Geräte (Router, Switches, Server, Firewalls) und Standorte.
Du kannst entscheiden, wer künftig für die Pflege zuständig ist – Doku ohne klare Verantwortung veraltet sofort.
Für ein self-hosted IPAM-Tool brauchst du einen Docker-Host. Für NetBox: Docker >= 20.10.10, containerd >= 1.5.6 und docker-compose >= 1.28.0. Prüfe das mit docker --version und docker compose version.
Grundkenntnisse in Subnetting/CIDR, DHCP und VLANs sind hilfreich – die passenden Anleitungen sind unten verlinkt.

Die folgenden Schritte sind herstellerübergreifend gedacht. Die Tool-Beispiele zeigen wir am Standard-Stack von NetBox und phpIPAM, das Prinzip gilt aber für jede Umgebung.

Schritt 1: Warum dokumentieren – und was das kostet, wenn du es nicht tust

Netzwerkdokumentation ist kein Selbstzweck. Sie zahlt sich an genau den Stellen aus, an denen es sonst teuer wird:

IP-Konflikte und Wildwuchs vermeiden: Ohne Plan werden Adressen doppelt vergeben – zwei Geräte mit derselben IP legen sich gegenseitig lahm.
Nachvollziehbarkeit: Wer hat wann was geändert? Eine Änderungshistorie beantwortet das, statt zu raten.
Notfall und Fehlersuche: Bei einem Ausfall zählt jede Minute. Wer Topologie, IPs und Zuständigkeiten parat hat, findet die Ursache schneller.
Übergabe an Dritte: Neue Kollegen, Dienstleister oder ein Inhaberwechsel – eine gute Doku macht das Netz übergebbar, statt es an eine Person zu binden.

Die Kernregel lautet: Die Doku muss immer aktuell sein. Jede Änderung wird sofort dokumentiert, am besten als fester Bestandteil des Change-Management-Prozesses. Eine Änderung ohne Doku ist der nächste IP-Konflikt mit Anlauf.

Schritt 2: Mindestumfang der Netzwerkdokumentation festlegen

Eine vollständige Netzwerkdokumentation besteht aus sieben Bausteinen. Diese Tabelle ist gleichzeitig deine 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

Trenne beim Netzplan unbedingt die physische von der logischen Sicht. Die physische Sicht zeigt, welches Kabel von welchem Patchpanel-Port auf welchen Switch-Port geht. Die logische Sicht zeigt Subnetze, Routing und Gateways. Beides in einem Bild wird unlesbar.

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

Damit der IP-Plan brauchbar bleibt, braucht jeder Eintrag dieselben Felder. Lege das Schema einmal fest und halte dich konsequent daran.

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

So sieht eine ausgefüllte Vorlage als einfache Tabelle aus – ideal als Startpunkt, bevor du auf ein Tool umsteigst:

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

Schritt 4: Das Subnetz-Schema planen

Der IP-Adressplan steht und fällt mit dem Subnetz-Schema. Plane die CIDR-Allokation vor dem Deployment – eine nachträgliche Änderung ist teuer und fehleranfällig. Die privaten Bereiche nach RFC 1918 sind deine Spielwiese:

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:

Lasse Lücken für Wachstum – vergib Subnetze nicht lückenlos hintereinander.
Gruppiere Hosts mit ähnlichem Bedarf (z. B. Server, Clients, VoIP, Management, Gäste) in eigene Subnetze.
Bevorzuge in Produktion /24 oder größer – das hält die Verwaltung einfach.
Vergib Adressen global eindeutig. Wenn später zwei Standorte per VPN gekoppelt werden, dürfen sich die Bereiche nicht überschneiden, sonst erzwingst du NAT oder produzierst Routing-Konflikte.

Ein bewährtes, sprechendes Schema kann z. B. die VLAN-ID im dritten Oktett spiegeln:

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.

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

Innerhalb jedes Subnetzes brauchst du eine klare Aufteilung. Wenn sich statischer Bereich und DHCP-Pool überlappen, sind IP-Konflikte garantiert. Teile jedes /24 sauber 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)

Der Unterschied zwischen statisch und Reservierung ist wichtig: Eine statische IP wird direkt am Gerät eingetragen (Server, Gateway). Eine DHCP-Reservierung bekommt das Gerät weiterhin vom DHCP-Server, aber immer dieselbe – gebunden an seine MAC-Adresse. Reservierungen sind leichter zentral zu verwalten, statische IPs sind unabhängig vom DHCP-Server. Wie du Pools und Reservierungen konkret konfigurierst, zeigt die DHCP-Anleitung unten.

Schritt 6: Tool-Wahl – NetBox oder phpIPAM

Für die digitale Quelle der Wahrheit gibt es zwei verbreitete, kostenlose self-hosted Optionen. Die Faustregel:

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

Kurz gesagt: phpIPAM nimmst du, wenn du vor allem IPs, Subnetze und VLANs sauber verwalten und schnell loslegen willst. NetBox nimmst du, wenn du eine vollständige Netz-, Geräte-, Rack- und Kabel-Dokumentation als zentrale Source of Truth mit API und Automatisierung brauchst – und den höheren Pflegeaufwand akzeptierst.

Schritt 7: phpIPAM per Docker einrichten

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

# Offizielles Repo holen
git clone https://github.com/phpipam-docker/phpipam-docker.git
cd phpipam-docker

# Stack starten (Services: phpipam-www auf Port 80, phpipam-cron, mariadb)
docker-compose -p phpIPAM up -d

Wichtig im Compose: 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. Die Default-DB-Werte sind:

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

Erst-Setup im Browser:

Rufe http://<host>/ auf und folge dem Setup: Datenbank installieren lassen, dann Admin-Passwort setzen.
Melde dich mit dem Default-Login an: Benutzer Admin, Passwort ipamadmin.
phpIPAM erzwingt direkt nach dem Login den Wechsel des Default-Passworts. Wähle ein starkes Passwort (mindestens 8 Zeichen, alphanumerisch).
Lege unter Administration → Sections eine Section (z. B. Standort) an, darunter deine Subnets. phpIPAM zeigt freien Platz und eine visuelle Subnetz-Darstellung automatisch an.

Nützliche Features: automatisches Subnetz-Scanning und Host-Status (pingCheck.php, discoveryCheck.php), VLAN-/VRF-/NAT-/Rack-Management, AD/LDAP/Radius-Anbindung, PowerDNS-Integration, REST-API sowie XLS-/CSV- und RIPE-Import für den Start.

Schritt 8: NetBox per Docker einrichten

NetBox ist die schwergewichtige Source of Truth. Der Docker-Stack 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://0.0.0.0:8000/

Lege den Admin-User 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

Wichtig für Produktion: Verwende versionierte Tags (vX.Y.Z-a.b.c bzw. vX.Y-a.b.c), nicht latest oder snapshot – sonst riskierst du unkontrollierte Upgrades und Datenmodell-Brüche.

Das NetBox-Objektmodell für IPAM ist hierarchisch und baut sich automatisch auf:

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

Zwei Besonderheiten: Die Auslastung wird je Prefix automatisch berechnet, und IP-Adressen werden immer Interfaces zugewiesen – nicht direkt Geräten. Wer das ignoriert, bekommt ein inkonsistentes Modell.

Schritt 9: Pflegeprozess und Disziplin etablieren

Das beste Tool nützt nichts ohne Prozess. Mit diesen Regeln bleibt die Doku dauerhaft verlässlich:

Eine Source of Truth: Entscheide dich für das IPAM-Tool oder die Tabelle – nie beides parallel pflegen, sonst driften die Daten auseinander.
Zuständigkeiten festlegen: Klare Verantwortung, wer einträgt und freigibt.
Change-Management: Jede Änderung wird im Zuge des Change-Prozesses dokumentiert – keine Allokation ohne Eintrag.
Regelmäßige Reviews/Reconciliation: Lass NetBox bzw. phpIPAM den Ist-Stand scannen (Discovery/Ping) und gleiche ihn gegen die Doku ab.
Versionierung und Backup: Sichere die Doku bzw. die IPAM-Datenbank regelmäßig.

Undokumentierte Allokationen sind die häufigste Ursache späterer Konflikte. Wer den Eintrag zur Pflicht macht, spart sich die Fehlersuche.

Troubleshooting / Typische Fehler

Doku veraltet sofort: Größte Stolperfalle. Pflege muss fester Teil des Änderungsprozesses sein – Änderung ohne Doku = nächster IP-Konflikt.
Zwei parallele Wahrheiten: Excel und IPAM-Tool driften auseinander. Eine verbindliche Source of Truth festlegen.
Überschneidende RFC-1918-Bereiche: Bei VPN/Standort-Merge kollidieren z. B. beidseitig 192.168.0.0/24 oder 192.168.1.0/24 → Routing-Konflikt, erzwingt NAT. Adressen global eindeutig vergeben.
DHCP-Pool und statischer Bereich überlappen: Garantierte IP-Konflikte. Subnetz klar in statisch / DHCP-Pool / Reservierungen aufteilen und im Plan ausweisen.
NetBox mit latest/snapshot: Führt zu unkontrollierten Upgrades und Datenmodell-Brüchen. Versionierte Tags nutzen.
NetBox-Voraussetzungen verfehlt: Zu alte Docker-/Compose-Version (Minimum Docker 20.10.10, compose 1.28.0) → Stack startet nicht.
NetBox-UI nicht erreichbar: docker-compose.override.yml fehlt oder Port 8000 nicht freigegeben. Und: IP-Adressen gehören an Interfaces, nicht direkt an Geräte.
phpIPAM Default-Login nicht geändert: Admin/ipamadmin ist ein kritisches Sicherheitsrisiko. Das Tool erzwingt den Wechsel – wähle trotzdem ein starkes Passwort.
phpIPAM ohne NET_ADMIN/NET_RAW: Automatisches Ping-Scanning, Host-Status und SNMP funktionieren nicht.
Mehrere phpipam-cron-Instanzen: Doppelte Discovery-/Scan-Jobs. Genau eine Cron-Replica betreiben.

Häufige Fragen

Excel oder ein IPAM-Tool – was ist besser?

Für kleine, stabile Netze reicht eine gepflegte Tabelle mit festem Spaltenschema. Sobald mehrere Subnetze, VLANs und Personen ins Spiel kommen, lohnt ein IPAM-Tool: Es zeigt freien Platz, scannt den Ist-Stand und verhindert Doppelvergaben. Entscheidend ist nicht das Werkzeug, sondern dass es die einzige Quelle der Wahrheit ist und konsequent gepflegt wird.

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

Für größere oder wachsende Netze ist 10.0.0.0/8 die beste Wahl, weil du viel Platz zum Strukturieren hast. 192.168.0.0/16 ist im Heim-/Kleinbereich üblich, kollidiert aber bei VPNs oft mit Gegenstellen. Wichtig in jedem Fall: Vergib Bereiche global eindeutig, damit spätere Standortkopplungen nicht in NAT-Workarounds enden.

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

Eine statische IP trägst du direkt am Gerät ein – sie funktioniert unabhängig vom DHCP-Server und eignet sich für Gateway und Server. Eine DHCP-Reservierung kommt weiterhin vom DHCP-Server, liefert aber per MAC-Bindung immer dieselbe Adresse. Reservierungen sind zentral einfacher zu verwalten, statische IPs sind robuster bei DHCP-Ausfall.

Reicht phpIPAM, oder brauche ich NetBox?

Wenn du vor allem IPs, Subnetze und VLANs verwalten und schnell starten willst, reicht phpIPAM völlig. NetBox lohnt sich, wenn du eine vollständige Source of Truth mit Geräte-, Rack- und Kabeldoku sowie API/Automatisierung brauchst – dafür nimmst du höheren Pflegeaufwand und ein striktes Datenmodell in Kauf.

Wie halte ich die Doku langfristig aktuell?

Binde die Pflege an das Change-Management: keine Änderung im Netz ohne Eintrag in der Doku. Lege eine zuständige Person fest, lass das IPAM-Tool regelmäßig den Ist-Stand scannen und gleiche ihn ab. So bleibt die Source of Truth verlässlich, statt schleichend zu veralten.

Muss ich physische und logische Topologie wirklich trennen?

Ja. Die physische Sicht (Kabel, Patchpanel, Ports) und die logische Sicht (Subnetze, Routing, Gateways) verfolgen unterschiedliche Zwecke. In ein Diagramm gepresst werden beide unlesbar. Zwei getrennte, jeweils saubere Pläne sind im Notfall deutlich schneller nutzbar.

Fazit

Eine belastbare Netzwerkdokumentation entsteht nicht aus einem Tool, sondern aus Struktur und Disziplin. Lege den Mindestumfang fest (Topologie, IP-/Subnetzplan, VLAN-Liste, Inventar, DNS-/Namenskonzept, Zuständigkeiten, Änderungshistorie), plane Subnetze global eindeutig und teile jedes Netz sauber in statischen Bereich, DHCP-Pool und Reservierungen. Für die digitale Quelle der Wahrheit nimmst du phpIPAM (schnell, leichtgewichtig) oder NetBox (umfassend, API-getrieben) – beide kostenlos per Docker. Den größten Unterschied macht am Ende der Pflegeprozess: Eine Quelle der Wahrheit, klare Zuständigkeiten und jede Änderung sofort dokumentiert. Dann ist dein Netz nachvollziehbar, notfallfest und übergebbar.

Weiterführende Anleitungen und Quellen

Subnetting und CIDR verständlich erklärt – für die konkrete Berechnung deines 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 deiner 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).