# Von der Switch-Konfiguration zu NetBox in einem Prompt

> Deine NetBox sagt das eine, dein Switch das andere. So gleichst du beide mit einer einzigen Anweisung in natürlicher Sprache ab — statt mit einem Python-Skript, das du für immer pflegen musst.

Canonical: https://www.toolmesh.io/de/blog/switch-config-to-netbox/

## Die Ausgangslage

Du betreibst NetBox als deine Single Source of Truth. Das funktioniert — bis es das nicht mehr tut.

Letzten Dienstag hat jemand einen Switch in Rack B getauscht. Zwei VLANs hinzugefügt, ein paar Interfaces umbenannt, einen Uplink verschoben. NetBox weiß von all dem nichts. Jetzt ist dein IPAM still und heimlich falsch, deine Cable Map lügt, und die nächste Person, die sich für eine Change-Planung auf NetBox verlässt, wird einen schlechten Nachmittag haben.

Die übliche Lösung ist ein Sync-Skript. Du schreibst ein paar hundert Zeilen, die die Live-Konfiguration ziehen, gegen NetBox diffen und die Deltas zurückschreiben. Es funktioniert. Dann liefert der Hersteller ein Firmware-Update, ein Interface-Namensschema ändert sich, du nimmst ein zweites Switch-Modell dazu — und jetzt pflegst du das Skript so sorgfältig wie das Netz, das es beschreibt.

Es gibt eine andere Form dafür.

## Die Anweisung

So sieht die Aufgabe aus, wenn das Tooling die Konnektivität trägt und du die Absicht:

> Lies die Live-Konfiguration vom Switch `perlman`. Vergleiche seine Interfaces, IP-Adressen und VLANs mit dem, was NetBox für dieses Gerät hat. Nenn mir jeden Unterschied und aktualisiere dann NetBox so, dass es zum Switch passt — aber halt an und zeig mir alles, was nach einer Löschung aussieht, bevor du es entfernst.

Das ist alles. Kein Skript. Morgen lautet die Anweisung „… und gleich noch den MikroTik in Rack B mit ab", und nichts in deiner Codebase muss sich ändern — weil es keine Codebase gibt. Die Anweisung ist die Automatisierung, und sie ist bewusst Wegwerfware.

## Was darunter tatsächlich passiert

Das ist keine Magie, und der Sinn dieser Serie ist, dass du genau sehen kannst, was läuft. Der Agent hat zwei Tool-Oberflächen vor sich, beide über einen einzigen ToolMesh-Endpoint bereitgestellt:

- den MikroTik-Switch, beschrieben durch eine [DADL](/de/dadl/)-Datei — rund dreißig Zeilen YAML machen aus seiner REST-API aufrufbare Tools wie `export_config`, `list_interfaces` und `list_ip_addresses`
- NetBox, auf dieselbe Weise — `netbox_get_device`, `netbox_create_interface`, `netbox_create_ip_address`, `netbox_update_*`

Im Code Mode feuert das Modell nicht einen Tool-Call pro Round-Trip ab. Es schreibt ein kurzes Stück JavaScript, das serverseitig läuft und nur das Ergebnis zurückgibt:

```javascript
// pull live state
const live = await toolmesh.mikrotik_perlman_list_interfaces({});
const liveIps = await toolmesh.mikrotik_perlman_list_ip_addresses({});

// pull NetBox's view of the same device
const device = await toolmesh.netbox_get_device({ name: "perlman" });
const nbIfaces = await toolmesh.netbox_list_interfaces({ device_id: device.id });

// diff happens here, in code, not in the model's head
return diff(live, liveIps, device, nbIfaces);
```

Eine Ausführung, ein Ergebnis zurück an das Modell. Ein Katalog aus achtzig NetBox-Tools plus den Switch-Tools würde rund 142.000 Tokens kosten, um ihn bei jedem Reasoning-Schritt zu annoncieren, wenn man sie alle als JSON-Schemas auflisten würde. Code Mode hält das näher an tausend, konstant, egal wie viele Backends du hinzufügst. Genau das ist der Unterschied zwischen „das ist nett in einer Demo" und „das kann ich gegen mein echtes Netz laufen lassen".

## Die Stellen, vor denen du Respekt hättest — abgesichert

**Nichts wird stillschweigend gelöscht.** Die Anweisung sagte: halt an und zeig mir Löschungen — und das wird am Gate erzwungen, nicht bloß dem guten Willen des Agenten überlassen. Zwei Kern-Mechanismen sorgen dafür. Zuerst die Autorisierung: Über OpenFGA kann ein Agent `netbox_create_*` und `netbox_update_*` halten, aber niemals `netbox_delete_*` — die Lösch-Tools werden für ihn schlicht nie freigeschaltet. Und die `ExecuteTool()`-Pipeline führt vor jedem Call, der das Backend erreicht, ein Pre-Gate aus, in dem eine kurze harte Regel — schlichtes JavaScript — alles abweist, was auf `netbox_delete_*` passt. Die Pipeline ist fail-closed: Kann eine Regel nicht entscheiden, wird der Call abgelehnt, nicht durchgewinkt. Anlegen und Updates laufen durch; Löschungen werden am Gate abgewiesen, sodass der Agent dir die gefundenen Löschungen zeigt und keine davon ausführt. Das schreibst du einmal, und es gilt für jeden Prompt, den du je ausführst.

**Keine Credentials im Prompt.** Der API-Token des Switches und der NetBox-Token erreichen das Modell nie. Sie liegen in ToolMeshs Credential Store und werden zum Zeitpunkt des Calls injiziert. Das Modell orchestriert; ein Geheimnis sieht es nie.

**Du kannst beweisen, was passiert ist.** Jeder Call landet in einem strukturierten Audit-Log — welches Tool, welches Gerät, was sich geändert hat, wie lange es gedauert hat, Erfolg oder abgelehnt. Wenn in drei Wochen jemand fragt, warum das Interface `sfp-sfpplus3` umbenannt wurde, ist die Antwort eine Abfrage und kein archäologisches Projekt.

## Was das ist — und was nicht

Wenn deine Reaktion ist „Config-to-NetBox mache ich seit zehn Jahren mit Nornir" — ja, das tust du, und gut. Die Behauptung hier ist nicht, dass das mächtiger ist als ein eigens gebautes Skript. Sondern dass es kein Skript zu pflegen gibt. Die Abgleich-Logik ist nicht an einen Hersteller, ein Namensschema oder eine NetBox-Version genagelt. Die Anweisung passt sich der Situation in einfacher Sprache an; die Tools darunter sind in YAML deklariert, das du in Git diffen kannst. Wenn sich die Situation ändert, änderst du einen Satz, keine Pipeline.

Das ist die ganze Wette: Netz-Zustand ändert sich ständig, also sollte die Schicht, die ihn abgleicht, der billige, wegwerfbare Teil sein — nicht der, den du babysittest.

## Willst du es in deinem eigenen Netz ausprobieren?

Die ehrliche Hürde hier ist das Setup: ToolMesh aufsetzen, die DADL für deinen Switch schreiben, NetBox verdrahten. Wenn genau diese Hürde dich aufhält, überspring sie. ToolMesh ist ein Angebot der [Dunkel Cloud GmbH](https://www.dunkel.cloud/), und wir richten dir eine persönliche Instanz auf einer eigenen VM ein — du behältst die volle Kontrolle und deine eigenen Credentials, wir übernehmen nur die anfängliche Verdrahtung, damit du sie auf deine Hardware richten und sehen kannst, ob der Abgleich gegen deine Realität wirklich standhält.

Dieses Angebot ist ernst gemeint, und es ist der schnellste Weg herauszufinden, ob das zu deiner Arbeitsweise passt.

---

Dies ist Beitrag 1 einer Serie über das Steuern von NetBox aus realer Infrastruktur: [MikroTik](https://dadl.ai/d/mikrotik), OPNsense, [Xen Orchestra](https://dadl.ai/d/xen-orchestra), [Hetzner](https://dadl.ai/d/hetzner-cloud), vSphere und UniFi. Jeder einzelne ist ein echter Workflow aus unserem eigenen Stack, keine konstruierte Demo.

ToolMesh ist Open Source (Apache 2.0). DADL ist eine offene Spezifikation (CC BY-SA 4.0) mit einer öffentlichen Registry unter [dadl.ai](https://dadl.ai/).