Dienstag, Juli 14, 2026

Netbox - Erstellen von Geräten (Devices) und Zuordnung von IP Adressen

Netbox sagt über sich selbst es könne als eine sogenannte “Single Source of Truth” fungieren. Man kann Netbox in diesem Kontext als Dokumentationswerkzeug für Geräte mit irgendeiner Art von Anschluss verstehen. Idealerweise steht dabei in Netbox die “Wahrheit” geschrieben, beispielsweise über das lokale Netzwerk und diese “Wahrheit” wird immer entsprechend an die verantworlichen Geräte/Dienste (z.B. Technitium) ausgerollt. Man kann so beispielsweise das gesamte Netzwerk in aller Ruhe vorab in Netbox planen und muss die so geplante Topologie dann nur noch an die verantwortlichen Dienste (DHCP, DNS usw.) ausrollen. Ab einer gewissen Komplexität und Größe macht so ein Vorgehen auch absolut Sinn. Dabei geht Netbox aber weit über bloße Netzwerkkonnektivität auf IP Ebene hinaus. Die Detailtiefe reicht bis zur konkreten Aderanzahl der Kabel und wenn man will sogar deren Farbe und Länge. Wie tief man gehen will kann man selbst entscheiden, passionierte Hobbybuchhalter können sich jedenfalls freuen…

Bildschirmfoto_20260714_164419.png

Netbox prüft die eingetragenen Werte dabei stets auf Plausibilität, eine IP kann bei Netbox beispielsweise nicht doppelt vergeben werden.
Was die Sache dabei aber noch wesentlich interessanter macht, ist der Umstand, dass sich Netbox via API abfragen lässt und die Daten wahlweise als CSV oder JSON (soweit ich bisher weiß) geliefert werden. Solche Abfragen kann man via Plugin dann mit Ansible Playbooks verknüpfen. Man kann aber auch externe Daten via Ansible in Netbox bringen, womit einer Automatisierung vieler Aufgaben fast keine Grenzen mehr gesetzt sind.
Es gibt z.B. bei Youtube bereits zahlreiche gute Anleitungen, die zeigen wie man in Netbox Geräte einrichtet und an selbige eine oder mehrere IP Adressen vergibt. Ich werde nur beschreiben, welche Punkte ich selbst bei Netbox verwende (die wenigsten brauchen vermutlich die volle Detailtiefe) und diesen Part auch recht kurz halten.
Bei Netbox muss man zunächst die eigene Organisation definieren. Hier ist die oberste hierarchische Ebene die Region. Wenn man ein oder mehrere VPS in einem US Rechenzentrum stehen hat, würde es bereits Sinn machen hier zwischen Deutschland und USA eine Unterscheidung zu machen. Die nächste Ebene sind für mich Standorte, hier habe ich in D aktuell zwei. Die Lokationen sind in meinem Fall die konkreten Räume an den beiden Standorten. Wenn man sich in der Hierarchie von oben nach unten durcharbeitet, hat man in der nächsten Ebenen meist die notwendigen Dinge in den Dropdown Menüs zur Auswahl. Sollte ein nowendiges (die mit *) Dropdown Menü keine Auswahl bieten, so muss man zunächst die entsprechenden Auswahlmöglichkeiten eine Ebene höher anlegen. Man braucht sich wegen den anderen Werten absolut keinen Stress machen, alles lässt sich natürlich nachträglich ändern und die Änderungen werden rekursiv überallhin übernommen.
Ähnlich verhält es sich beim Anlegen neuer Geräte. Zunächst braucht man einen Hersteller (Z.B. Apple), als nächstes braucht man einen Gerätetyp (z.B. Mac Mini M1) und eine passende Geräterolle. Geräterolle ist zwingend vorgeschrieben, da die Vorauswahl scheinbar nicht passt, habe ich zwei neue Geräterollen in bestem Denglish als “Mobile User Endgerät” (Wifi) und “Static User Endgerät” (LAN Kabel) angelegt. (Wird sich vermutlich noch zeigen, ob das so richtig/sinnvoll ist) Erst nach diesen Vorarbeiten konnte ich ein neues physisches Gerät anlegen. (Beispiel)

Bildschirmfoto_20260714_170335.png

Das neue Gerät hat mehrere Schnittstellen u.a. Wifi, LAN, USB, Bluetooth usw., in dem konkreten Beispiel gehe ich nur auf die LAN Schnittstellen ein, weitere Schnittstellen kann man bedarfsweise jederzeit auch noch nachträglich anlegen. Die neue Schnittstelle nenne ich schlicht LAN. Es kann bei den Schnittstellen durchaus mehrere namensgleiche Schnittstellen geben, unterschieden werden solche Schnittstellen dann anhand des zugeordneten physischen Gerätes und der ebenfalls zugeordneten MAC Adresse der jeweiligen Schnittstelle. Die MAC Adresse(n) bestimmter Geräte lassen sich zwar ändern (LXCs, VMs, Handies als Anti Tracking Maßnahme usw.) und sind vermutlich deswegen kein “Netbox Pflichtfeld”, ich nutze aber fast ausschließlich feste MAC Adressen und daher ist die MAC Adresse bei der Schnittstelle für mich persönlich ebenfalls ein “Pflichtfeld”. Ausserdem benötige ich die MAC Adresse später, wenn ich die IP Adressvergabe über Ansible/Netbox steuern will.

Bildschirmfoto_20260714_172818.png

Zu guter Letzt kann man über den Punkt IPAM nun beim Unterpunkt IP Adressen eine neue IP Adresse anlegen (CIDR Notation ist Pflicht) und diese mit der soeben erstellten Schnittstelle verknüpfen.

Bildschirmfoto_20260714_172955.png

Man kann einer Schnittstelle auch mehrere IP Adressen zuordnen, das benötigt man beispielsweise, wenn man auf dieser Schnittstelle zusätzlich ein VPN mit eigener IP nutzt o.ä.

Zentrale Verwaltung und Dokumentation der Netzwerkinfrastruktur mit Netbox und Ansible (TBC…)

Im Laufe der letzten Jahre ist mein “IT Fuhrpark” erheblich angewachsen. Inzwischen werkeln an zwei Standorten, die miteinander via Tailscale verbunden sind, 4 PVE-Instanzen mit knapp 40 LXCs und diversen VMs in meinen beiden Subnetzen. Eventuell kommt Ende des Jahres sogar noch ein weiteres Subnetz mit zusätzlichen physischen und virtuellen Geräten hinzu.
Aktuell nutze ich zur Dokumentation meiner Netzwerktopologie ein lokales Wiki mit diversen Tabellen, was sehr unübersichtlich ist und wegen dem rein deklarativen Charakter auch fehleranfällig. Ich musste also eine zentrale Lösung finden, die zum einen meine Netzwerktopologie besser dokumentiert/abbildet und idealerweise gleichzeitig diese Topologie auf logische Fehler prüft. Tatsächlich gibt es so etwas bereits… 😃 s. u.
Ein großer Teil der Verwaltung der PVE- und Proxmox-Backup-Server-(PBS)-Instanzen lässt sich mit dem Proxmox Data Manager konsolidieren. Die IP-Adressen-Verwaltung (IPAM) und Pflege der beiden Technitium-DNS-&-DHCP-Server ist jedoch bei so vielen physischen und virtuellen Geräten inzwischen in richtige Arbeit ausgeartet, und bei einer Fehlkonfiguration (z. B. IP versehentlich doppelt vergeben) warnt einen Technitium nicht wirklich. Man kann zwar via Ansible die Technitium-Server mit den PVE-Instanzen „zusammenbringen“, aber das ist nicht unbedingt intuitiv, und dokumentieren muss man es dann trotzdem noch irgendwo.
Nach entsprechender Recherche bin ich schließlich bei dem Duo Netbox/Ansible gelandet. Ich teste derzeit beide Tools im Zusammenspiel und weiß bereits, dass man damit sogar noch wesentlich mehr tun kann, als nur IPAM und DNS zentral zu steuern. Ich werde daher den beiden Tools demnächst diverse Beiträge widmen, um die Einrichtung und die Möglichkeiten zu dokumentieren. Da ich dabei vermutlich Fehler machen werde, sollte man wie immer bei meinen Anleitungen etwas auf der Hut sein. Für Hinweise bei Fehlern meinerseits bin ich wie immer sehr dankbar.
Netbox und Ansible gibt es erfreulicherweise bei den community-scripts.org (ehemals Proxmox Helper Scripts). Ansible ist dabei Teil des Pakets Semaphore UI, einer praktischen GUI für Ansible.
TBC…