Netzwerktopologie für ein Robotik- und KI-Compute-Lab

Ein Robotiklabor ist kein Büro, kein Rechenzentrum und kein Homelab. Es ist ein kleines, aber ungewöhnlich anspruchsvolles Netzwerk: eine Handvoll Geräte mit sehr unterschiedlichen Traffic-Profilen teilen sich dieselbe Leitung. Ein Humanoid streamt Stereovideo an einen Inferenz-Server. Eine Dev-Workstation lädt einen 70 GB großen Modell-Checkpoint. Ein Vierbeiner läuft umher und sucht seine Dockingstation. Ein IPMI-Port meldet still und leise eine Lüfterdrehzahl.

Stimmt die Topologie nicht, sind die Symptome übel und indirekt: Ein Roboter stockt, sobald eine Kollegin ein Docker-Image pusht; die Tail-Latenz des Inferenz-Servers verdoppelt sich, wenn sich jemand ins WLAN einbucht; die Gradienten-Synchronisation zu Ihrer Fine-Tuning-Maschine zeigt zur Mittagszeit plötzlich Spitzen von 200 ms. Stimmt sie, bleibt das Netzwerk unsichtbar — und mehr wollen Sie von ihm gar nicht.

Dieser Artikel beschreibt den richtigen Zuschnitt für dieses Netzwerk im Jahr 2026. Zielgruppe: Integratoren und Laborbauer, die das „Lab in a Box“ aufbauen — ein bis vier Roboter, ein oder zwei Kentino AI Inferenz-Server, ein paar Dev-Workstations und die Storage- und Management-Komponenten, die alles zusammenhalten. Keine Hyperscaler-Referenzarchitektur. Kein Homelab-Sparbau. Genau die Mitte dazwischen.

Das Ziel: „Lab in a Box“

Das Referenz-Deployment für diesen Artikel:

• 1–4 Roboter — Humanoide, Vierbeiner oder eine Mischung. Primär Wi-Fi 6E, während der Entwicklung optional kabelgebunden.
• 1–2 Kentino AI Inferenz-Server — 4× oder 8× GPU (5090 / RTX Pro 6000 Blackwell), mit vLLM / SGLang für VLMs und LLMs.
• 1–2 Storage-/NAS-Systeme — Datensätze, Checkpoints, aufgezeichnete Sensorlogs. Meist ein ZFS-System mit NVMe-Cache.
• 2–6 Dev-Workstations — Entwickler, die ROS 2 und Isaac Sim fahren, Fine-Tunes trainieren und Daten hin- und herkopieren.
• Management-Plane — IPMI/BMC auf jedem Server, Switches, APs, ein lokaler DNS-/DHCP-Host.

Summe: 15–40 aktive Netzwerkgeräte. Elektrisch könnte ein einziger Switch das tragen. Dass im folgenden Design zwei Switches stehen, liegt nicht an der Kapazität — sondern an Fehlerdomänen, PoE-Budget und dem Wunsch, Roboter-Traffic und GPU-Traffic auf getrennten physischen Leitungen zu halten, damit keiner dem anderen die Bandbreite wegnimmt.

Physische Topologie

Zwei physische Switches, eine Firewall, ein oder zwei APs. Die Kentino AI Server hängen mit 25 GbE am Core; der Access-Switch bündelt Workstations und APs; Roboter verbinden sich über eine eigene 6-GHz-SSID.

Zwei physische Switches, eine Firewall, ein oder zwei APs. Die Kentino AI Server und das Storage-System hängen mit 25 GbE am Core-Switch. Der Access-Switch nimmt die kabelgebundenen, aber langsameren Geräte auf — Workstations, APs, IPMI, Kameras — und ist mit 10 GbE am Core angebunden. Die Roboter kommen über Wi-Fi 6E auf einer eigenen SSID herein.

Warum 25 GbE zwischen Core und Kentino AI? Weil die ConnectX-6 Lx mit zwei SFP28-Ports 2026 die günstigste ernstzunehmende Karte ist (Straßenpreis €700–€900, gebraucht teils weniger) und 25 GbE für das Inferenz-Fan-in eines einzelnen Servers mehr als ausreicht. Ein 70B-Modell in Q4, das gleichzeitig Tokens an vier Roboter streamt, bewegt sich im Bereich zweistelliger Mbit/s. Das Verschieben eines Modell-Checkpoints ist das Bandbreiten-Ereignis des Tages — und 25 GbE schafft 100 GB in rund 35 Sekunden. Wer Multi-Node-Training fährt, braucht 100 GbE — behandelt in N01 und N08 — aber das ist ein anderes Netzwerk als das in diesem Artikel.

Dimensionierung der Geschwindigkeitsstufen

Zwei Dinge, die man verinnerlichen sollte:

• In einem Labor mit einem einzigen Server brauchen Sie kein 100 GbE. Es wird spezifiziert, weil das Datenblatt beeindruckend aussieht. Die tatsächliche Dauerlast des Kentino AI Servers im Netz sind „Tokens raus“ (Mbit/s) plus gelegentliche Checkpoint-Transfers (einstellige Gb/s). In einem reinen Inferenzlabor ist die Leitung nie der Engpass.
• WLAN ist immer der langsamste Hop. Planen Sie entsprechend. Eine gute 6-GHz-Verbindung zu einem Wi-Fi-6E-Client liefert auf 10 m Sichtlinie 1.2–1.8 Gb/s realen Durchsatz bei 3–8 ms Latenz und ±2 ms Jitter unter vernünftigen Bedingungen. Sensor-Streams eines Roboters (eine oder zwei RGB-D-Kameras mit je 1080p30) brauchen dauerhaft ~150–300 Mb/s; Sie haben also reichlich Reserve — bis sich jemand anderes in dieselbe SSID einbucht.

VLAN-Segmentierung

Dieses Netzwerk hat nicht aus Gründen der Unternehmenshygiene sechs VLANs. Es geht darum, dass das Fehlverhalten eines Geräts nicht den Betrieb eines anderen ruinieren kann.

Die Trennung, über die viele stolpern: Roboter und Kentino AI liegen in unterschiedlichen VLANs, obwohl sie permanent miteinander sprechen. Das Inter-VLAN-Routing ist Aufgabe der Firewall bzw. des Routers, und genau dort gehört durchgesetzt, wer mit wem sprechen darf. Lägen Roboter und Kentino AI im selben VLAN, hätte ein kompromittierter Roboter (und Consumer-Humanoide bringen reichlich Angriffsfläche mit) flachen L2-Zugriff auf den GPU-Server. In jedem halbwegs ernsthaften Deployment ist das ein klares „Nein“.

Die zweite Trennung, für die es sich zu kämpfen lohnt: Die Management-Plane bekommt ihr eigenes VLAN, Punkt. IPMI-/BMC-Schnittstellen werden seit zwei Jahrzehnten mit Hersteller-Backdoors ausgeliefert, und Sie sollten davon ausgehen, dass das so bleibt. Sie bekommen ihr eigenes Subnetz, ihre eigenen Zugriffsregeln, und niemand routet zu ihnen außer einem Admin-Laptop im Management-VLAN.

Firewall-Regeln

Zwischen VLANs gilt grundsätzlich Default Deny. Dann die Ausnahmen:

Zwei dezidierte Regeln, auf die wir ausdrücklich hinweisen:

• Roboter bekommen keinen Internetzugang. Dagegen gibt es Widerstand, weil es die Telemetrie- und Firmware-Update-Prozesse des Herstellers unterbricht. Gut so. Geben Sie den konkreten Update-Server des Herstellers in einem Wartungsfenster frei und schließen Sie ihn danach wieder. Der Normalzustand lautet: „Dieser Roboter kann nicht nach Hause telefonieren.“
• Der WAN-Zugang von Kentino AI ist bedarfsgesteuert. Für einen Modell-Download oder Container-Pull öffnen Sie 443. Sonst bleibt er zu. Der Inferenz-Server hat im Web nichts zu suchen, und Sie wollen nicht, dass ausgerechnet das Skript eines neugierigen Entwicklers mit curl zum Einfallstor wird, über das ein Wurm Ihren Datensatz abzieht.

WLAN-Einrichtung

Der mit Abstand häufigste Fehler beim WLAN-Aufbau im Robotiklabor lautet: „Wir hängen die Roboter einfach an die Büro-SSID.“ Diese SSID teilen sich Smartphones, Laptops, Drucker, ein smarter Kühlschrank und drei Leute in Teams-Calls. Die Latenzschwankungen sind brutal, und das reaktive Verhalten des Roboters bricht zusammen.

Richtig ist:

• Eine SSID pro VLAN. „lab-robots“ auf VLAN 10, „lab-dev“ auf VLAN 30, „lab-guest“ auf VLAN 99. Das mgmt-VLAN ist drahtlos überhaupt nicht präsent.
• Die Robotik-SSID läuft ausschließlich auf 6 GHz. Kein 2.4 GHz, kein 5-GHz-Fallback. Ja, ältere Geräte können sich damit nicht einbuchen — genau das ist der Sinn. Auf 6 GHz gibt es dramatisch weniger Konkurrenz, weil der Bestand an Altgeräten dort 2026 praktisch null ist.
• Kanalbreite 80 MHz, nicht 160. 160 MHz sieht auf dem Datenblatt besser aus, aber zwei 160-MHz-APs im selben Gebäude funken sich gegenseitig zu. 80 MHz auf 6 GHz liefern vier bis sechs saubere Kanäle und vorhersagbare Latenz.
• Ein AP pro ~60–80 m² Roboter-Arbeitsfläche, möglichst mit Sichtverbindung. Hat das Labor Wände, kommt ein AP dazu. Roaming funktioniert mit Wi-Fi 6E und aktiviertem 802.11r/k/v gut, aber ein Roboter mitten in einer Aufgabe freut sich nicht über ein Roaming-Ereignis.
• Deaktivieren Sie Airtime Fairness für die Roboter-SSID. Die Voreinstellung bevorzugt langsamere Clients; Sie wollen aber, dass der Roboter — der einzige Nutzer dieser SSID — jeden Airtime-Slot bekommt.

Zur Hardware 2026: UniFi U6 Enterprise (Wi-Fi 6E, ~€450) oder die neueren U7 Pro / E7 (Wi-Fi 7, €189 / €499+) sind die kosteneffizienten Optionen. Die Aruba-650-Serie und die Cisco-Meraki-MR-Serie sind die Enterprise-Alternativen zum 2–3-fachen Preis; die Management-Ebene ist angenehmer und die Funkmodule kommen mit hoher Client-Dichte besser zurecht — beides braucht ein einzelnes Labor mit zwei Robotern schlicht nicht.

Zeitsynchronisation — PTP und NTP

Uhrendrift zwischen Roboter und Server zerstört die Sensorfusion auf subtile und peinliche Weise. 20 ms Versatz lassen eine Stereo-Tiefenpipeline Geisterobjekte erzeugen. 100 ms Versatz lassen den Manipulationsplaner glauben, der Greifer sei irgendwo, wo er nicht ist.

Zwei Lösungsstufen:

• NTP mit chronyd gegen einen lokalen Stratum-1-Server (ein Raspberry Pi mit GPS-HAT, ~€80 komplett, oder die Firewall als Stratum-2). Erreicht ~1 ms Genauigkeit im kabelgebundenen LAN, ~5–20 ms über WLAN. Für die meiste Robotikarbeit ausreichend.
• PTP (IEEE 1588v2) mit Hardware-Timestamping auf Switches, die das unterstützen. Die MikroTik-Serien CRS3xx/CRS5xx beherrschen PTP Boundary Clock mit Synchronisation im Nanosekundenbereich; Aruba CX 6300 und Cisco Catalyst ebenfalls. Erreicht auf kabelgebundenen Pfaden unter einer Mikrosekunde, über WLAN unter einer Millisekunde.

Für 1–2 Roboter reicht NTP. Betreiben Sie chronyd auf jedem Knoten, richten Sie es auf den lokalen Master aus, überwachen Sie den Offset und alarmieren Sie ab >5 ms Drift. Ab vier Robotern oder bei jedem Deployment mit maschinenübergreifender Multi-Sensor-Fusion läuft PTP auf der kabelgebundenen Seite, NTP als Fallback. In jedem Fall gilt: überwachen Sie die Drift. Die Zahl der Labore, die „Zeitsynchronisation haben“, weil vor zwei Jahren einmal apt install ntp gelaufen ist, ist groß.

DNS, DHCP und IPAM

Ein lokaler Resolver auf der Management-Plane, Punkt. Pi-hole oder Unbound auf einer kleinen VM erledigt das. Die Gründe:

1. Roboter und Inferenz-Server müssen vllm.lab.local, nas.lab.local usw. auflösen können, ohne einen Umweg über das WAN.
2. Sie wollen eine einzige Stelle haben, an der ein Hosts-Eintrag ergänzt wird, wenn ein neuer Kentino AI Endpunkt dazukommt.
3. Pi-hole bringt gratis eine netzwerkweite Werbe- und Telemetriesperre mit, die streunenden Phone-Home-Traffic der Hersteller von Ihren Leitungen fernhält.

DHCP je VLAN, konfiguriert auf Firewall bzw. Router (UDM Pro Max, OPNsense und pfSense können das alle sauber). Reservierungen für alles, was zählt — Roboter, Server, APs, IPMI, Switches, NAS. Dynamische Pools sind nur für Gäste und kurzlebige Workstations da. Ein Roboter, der bei jedem Neustart eine andere IP bekommt, ist ein Roboter, dessen ROS-2-Launch-Dateien jeden Dienstag kaputtgehen.

Monitoring

Ein Labor ohne Monitoring ist ein Labor, in dem Probleme an ihren Folgen diagnostiziert werden. Betreiben Sie den Standard-Stack auf der Management-Plane:

• Prometheus scrapt SNMPv3 der Switches, NIC-Zähler (node_exporter), GPU-Metriken (dcgm_exporter) und Metriken des Inferenz-Servers (vLLM exportiert Prometheus nativ).
• Grafana Dashboards: Auslastung je Port, Durchsatz je VLAN, GPU-Temperatur und -Auslastung, PTP-/NTP-Drift, Verfügbarkeit der Roboterverbindung.
• Alerts — und zwar solche, die tatsächlich auslösen: PFC-Pause-Zähler > 0 an einem Port (heißt, jemand staut RDMA, das sollte es in diesem Netz gar nicht geben — prüfen Sie es trotzdem), GPU-Temperatur > 80 °C, Zeitdrift > 5 ms, Anomalien bei der AP-Client-Zahl.

SNMPv3, nicht v2c. Das Labor ist klein genug, dass der Mehraufwand bei der Konfiguration fünfzehn Minuten beträgt — und der Sicherheitsgewinn real ist.

Konkrete Stückliste — 1 Server, 2 Roboter, 4 Workstations

Eine funktionierende, ehrlich kalkulierte Einkaufsliste für das Referenz-Deployment, Mitte 2026 in EUR netto:

Zum Vergleich: Allein der Kentino AI Server mit 8 GPUs liegt bei €40–70k, die beiden Humanoiden bei je €30–80k. Das Netzwerk macht 5–10 % der Gesamtausgaben aus — und ist der Teil, der am ehesten darüber entscheidet, ob ein Labor funktioniert oder nicht.

Wenn das Budget knapp ist, sind das die vertretbaren Streichungen: den Core-Switch auf einen MikroTik CRS504-4XQ-IN herunterstufen (4× QSFP28, Breakouts auf 16× 25 GbE, ~€700) und die geringere Portzahl akzeptieren; nur einen AP einsetzen, wenn die Arbeitsfläche <60 m² beträgt; auf die GPS-NTP-Quelle verzichten und mit chrony über das WAN leben.

Häufige Fehler

Grob danach sortiert, wie oft sie zuschlagen:

• Robotik-Traffic mit dem allgemeinen Büro-WLAN mischen. Latenzschwankungen zerstören reaktives Verhalten. Der erste Schritt bei jedem „mein Roboter zuckt“-Anruf lautet: „Geben Sie ihm eine eigene SSID auf 6 GHz.“
• Zu kleine Puffer in billigen Switches. Ein 10G-Switch mit 8 Ports für €200 kommt mit zwei Geräten gut zurecht und bricht ein, sobald vier Knoten denselben Uplink beanspruchen. KI-Traffic ist burstig; die Switch-Puffer fangen die Spitzen ab. Der günstigste ernstzunehmende Deep-Buffer-Switch in diesem Artikel ist der Aruba CX 6300 (8/16/32 MB Shared Buffer); der MikroTik CRS5xx hat flachere Puffer, reicht für ein Labor mit einem Server aber aus.
• Kein PTP-Master, kein NTP-Audit. Zeitsynchronisation „funktioniert“, bis sie es nicht mehr tut — und dazwischen scheitert die Sensorfusion lautlos. Offset überwachen und alarmieren.
• PoE-Budget falsch gerechnet. Ein Switch wirbt mit „PoE++“, und dann stellt sich heraus, dass sein Gesamtbudget 200 W beträgt, wovon die Hälfte auf Kameras entfällt, von denen Ihnen niemand erzählt hat — und der AP bricht beim Booten weg. Addieren Sie die Wattzahlen und lassen Sie 30 % Reserve.
• Roboter darf nach Hause telefonieren. Firmware-Update des Herstellers an einem Dienstagmorgen, das ein neues Modell lädt, das die Inferenzlatenz an Bord verändert, das das Greifer-Timing zerschießt. Jedes Mal. Sperren Sie den WAN-Zugang des Roboters per Firewall und steuern Sie Updates manuell.
• Kein Monitoring, bis etwas kaputtgeht. Das Labor läuft sechs Monate lang einwandfrei. Dann wirft der AP zweimal täglich Clients raus, und eine Woche lang merkt es niemand, weil es keine Dashboards gibt. Bis jemand nachgräbt, haben sich vier andere Dinge geändert, und niemand kann noch sagen, was zuerst ausgefallen ist.

Ehrliche Einschätzung

Die meisten Robotiklabore überkonstruieren ihr Netzwerk und unterdimensionieren genau die Teile, auf die es ankommt. Man spezifiziert 100-GbE-Backbones für Inferenzlabore mit einem einzigen Server und hängt den Roboter dann ans Büro-WLAN. Man kauft einen Cisco Catalyst 9300X mit tiefen Puffern und fährt dann flaches L2 ganz ohne VLAN-Segmentierung.

Das 80/20-Design für ein Labor mit einem Server und 1–4 Robotern im Jahr 2026 ist klein und unspektakulär:

• 25 GbE zwischen Core-Switch und Kentino AI Server. Eine NIC, ein DAC, fertig.
• 10 GbE zwischen Core und Access. Zwei DACs.
• Ein Core-Switch, ein Access-Switch, eine Firewall, ein oder zwei APs.
• Sechs VLANs, Firewall mit Default Deny, getrennte SSIDs je Rolle.
• NTP aus lokaler Quelle, überwacht.
• Prometheus + Grafana auf einer kleinen VM.

Netzwerkausgaben gesamt: unter €7k. Inbetriebnahme: rund eine Woche, wenn die Verkabelung steht. Das trägt ein echtes Produktivlabor; die nächste Stufe — 100-GbE-Backbone, geroutetes Clos, Deep-Buffer-KI-Switches — ist für Multi-Server-Training gedacht und damit das Terrain von N04, N08 und K02.

Dies ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Compute, Robotik und den Systemen, die beides verbinden. Anmerkungen und Korrekturen gern an info@kentino.com.