NetBox als Source of Truth: erst das Soll, dann die Playbooks

Die Szene gibt es in fast jedem gewachsenen Netz: Ein VLAN soll auf zwölf Switches, jemand öffnet die IP-Liste — zuletzt geändert vor vier Monaten, von einem Kollegen, der nicht mehr da ist. Daneben eine zweite Liste im Teamlaufwerk und eine dritte im Kopf des Dienstältesten. Automatisieren lässt sich so nicht. Nicht, weil das Werkzeug fehlt, sondern weil niemand sagen kann, was gelten soll.

Genau diese Lücke füllt eine Source of Truth: die eine Instanz, die den Soll-Zustand des Netzes hält und ihn maschinenlesbar macht. Das verbreitetste Werkzeug dafür ist NetBox — die Dokumentation beschreibt es als Verbindung von IP-Adressverwaltung (IPAM) und Infrastrukturverwaltung (DCIM) mit APIs, ausdrücklich als „Source of Truth“, die Netzwerkautomatisierung antreibt. Seit der Freigabe als Open Source 2016 setzen tausende Organisationen es genau so ein.

Das Soll ist der Punkt — nicht das Ist

Der häufigste Fehlstart sieht vernünftig aus: erst einmal das bestehende Netz automatisch einsammeln, dann hat man ja eine Datenbasis. Die NetBox-Dokumentation rät davon ausdrücklich ab: NetBox bildet den gewünschten Zustand eines Netzes ab, nicht seinen Betriebszustand — und vom automatisierten Import des Live-Zustands wird klar abgeraten. Daten sollen von einem Menschen geprüft werden, bevor sie hineinkommen.

Der Grund ist kein Purismus. Wer das Ist importiert, erklärt den Wildwuchs zum Standard: das vergessene VLAN 99, die Trunk-Konfiguration von 2019, die IP aus dem falschen Bereich — alles wird mit dem Import zur dokumentierten Wahrheit geadelt. Danach automatisiert man den Zufall, nur schneller.

Was hineingehört — und in welcher Reihenfolge

NetBox modelliert die Objekte, aus denen ein Netz tatsächlich besteht: Standorte, Geräte und Gerätetypen, Interfaces, Verkabelung, VLANs, VRFs, Präfixe und IP-Adressen. Die Reihenfolge der Befüllung ist keine Geschmacksfrage — sie entscheidet, ob die Daten tragen:

1. 01

   Standorte und Geräte

   Sites, Gerätetypen, Geräte mit Rollen (Access, Distribution, Core, Firewall). Die Rolle ist später der Anker der Automatisierung.

2. 02

   Verkabelung

   Uplinks und Stacks als dokumentierte Verbindungen. Erst damit werden Aussagen wie „hängt hinter“ prüfbar.

3. 03

   IPAM von oben nach unten

   Erst Aggregat und Präfixe, dann Einzeladressen. Eine IP ohne Präfix-Kontext ist ein Zettel, kein Datensatz.

4. 04

   VLANs und VRFs

   Mit Namen, Nummern und Zuständigkeit — die Ebene, auf der Segmentierungsvorhaben konkret werden.

5. 05

   Primäre IPs und Plattform

   Jedes Gerät bekommt seine Management-Adresse und Plattform-Angabe. Genau diese Felder machen das Gerät für Werkzeuge erreichbar.

Und: Es braucht keine perfekte Gesamterfassung, bevor der erste Nutzen entsteht. Eine Domäne — etwa ein Standort mit seinen Access-Switches — vollständig und geprüft ist mehr wert als das ganze Netz zur Hälfte. Ab da gilt die Regel, die den Unterschied macht: Jede Änderung läuft zuerst durch die Source of Truth. Wie man ein gewachsenes Netz überhaupt in eine dokumentierbare Ordnung bringt, haben wir im Beitrag über das Neuordnen gewachsener Netze beschrieben.

Wo Ansible übernimmt

Der erste Handgriff, der sich sofort auszahlt: Ansible pflegt kein eigenes Inventar mehr. Das Inventory-Plugin nb_inventory der netbox.netbox-Collection liest die Hosts direkt aus NetBox und baut Gruppen aus dem, was dort ohnehin steht — Standorten, Rollen, Plattformen, Tags. Die Hostliste, die sonst neben der Realität herläuft, entfällt ersatzlos.

Für die Umsetzung auf Cisco-Geräten steht die cisco.ios-Collection (Stand: Version 11.5) bereit — mit Ressourcen-Modulen für genau die Objekte, die in NetBox modelliert sind: ios_vlans, ios_interfaces, ios_l2_interfaces und ios_l3_interfaces, dazu ios_ospfv2, ios_acls, ios_ntp_global und weitere. Das Soll kommt aus NetBox, das Modul stellt den Zielzustand her — statt Befehlsfolgen zu tippen, die auf jedem Gerät anders enden.

• Inventar nie doppelt führen. Hosts, Gruppen und Erreichbarkeit kommen aus NetBox — eine zweite Liste ist der Anfang der nächsten Lüge.
• Soll rendern statt Befehle sammeln. VLANs, Interfaces und Routing beschreiben, nicht als CLI-Historie pflegen.
• Kein Lauf ohne Probelauf. Erst der Vorschau-Lauf mit Änderungsdiff, dann die Ausführung — der Diff vor dem Change ist das Dokument, über das man sprechen kann.
• Rollen statt Hostlisten. „Alle Access-Switches am Standort X“ ist eine NetBox-Abfrage — und bleibt richtig, wenn der dreizehnte Switch dazukommt.

Selbst ausprobieren: vom geprüften Soll zum Konfigurations-Diff

Das NetBox-Lab als ZIP herunterladen und die Anleitung mit Prüfkommandos lesen. Sie erhalten zwei erfundene Switches, ein vorbereitetes Soll-Inventar, lokale Ausgangskonfigurationen und einen kleinen Python-Generator. Python ab 3.10 genügt; zusätzliche Pakete, NetBox-Instanz und Zugangsdaten sind für den Versuch nicht erforderlich.

1. 01

   Soll lesen und die Änderung benennen

   Nach dem Entpacken fixture.json mit baseline/ vergleichen: sw-ber-01 in lab-berlin soll zusätzlich VLAN 30 mit Namen GUEST erhalten. sw-ham-01 in lab-hamburg behält VLAN 10 und 20. Die Prüfmarkierung in der Datei gehört zum Beispiel; im eigenen Ablauf ersetzt sie keine tatsächliche Prüfung.

2. 02

   Lokal rendern

   Im entpackten netbox-lab-Verzeichnis python3 -B lab.py ausführen. Unter output/ entstehen inventory.ini, zwei Konfigurationsausschnitte, zwei Diff-Dateien und report.json. Ein vorhandenes Ausgabeverzeichnis wird nicht überschrieben; die Anleitung beschreibt einen zweiten Lauf.

3. 03

   Ergebnis gegen die Erwartung prüfen

   python3 -B test_lab.py prüft die erwarteten Dateien, die Zuordnung zum richtigen Gerät und fehlerhafte Eingaben in temporären Verzeichnissen. Wer Ansible installiert hat, kann das erzeugte Inventar zusätzlich mit ansible-inventory auflisten, ohne Geräte zu kontaktieren.

Die Brücke zum echten NetBox ist der Datenvertrag. Im produktiven Ablauf kann netbox.netbox.nb_inventory Geräte aus der NetBox-API lesen, mit device_query_filters eingrenzen, Gruppen über group_by bilden und mit config_context: true Kontextdaten als Hostvariablen übernehmen. Der Download übt diese Übergabe mit einer festen Datei und einem erzeugten INI-Inventar; er implementiert das Plugin nicht. Für eine echte Integration müssen Felder und Filter an der eingesetzten NetBox- und Collection-Version geprüft werden.

Der Kreis schließt sich im Betrieb

Mit Event Rules meldet NetBox Änderungen von sich aus: Ein neues Präfix, ein geändertes Gerät kann per Webhook eine Pipeline anstoßen, statt darauf zu warten, dass jemand daran denkt. Und die Drift-Frage — weicht das Netz vom Soll ab? — wird von einer Vermutung zu einem wiederkehrenden Lauf mit Ergebnisliste.

Zur Einordnung neben den Plattformen: NetBox ersetzt weder Catalyst Center noch das Meraki-Dashboard — es beantwortet eine andere Frage. Die Arbeitsteilung, die trägt, haben wir im Beitrag zur Catalyst-Center-API beschrieben: NetBox bleibt das Inventar und die Soll-Instanz, die Plattform übernimmt Onboarding, Software-Wellen und Assurance für ihre Gerätewelt.

Wie wir diese Kette aufbauen, zeigt der dokumentierte Automation-Change. Für den Einstieg trennen wir NetBox und Datenpflege, Ansible-Ausführung und API-Integration mit Datenvertrag und Fehlerfällen. Der erste Schritt bleibt: eine Domäne wählen, den Sollzustand pflegen und Änderungen nachvollziehbar darüber führen.