Network Topology for a Robotics + AI Compute Lab

A robotics lab is not an office, not a data centre, and not a home lab. It is a small but unusually demanding network: a handful of devices with very different traffic profiles all sharing the same wire. One humanoid streams stereo video to an inference server. A dev workstation pulls a 70 GB model checkpoint. A quadruped paces around looking for its dock. An IPMI port quietly reports a fan tach.

Get the topology wrong and the symptoms are awful and indirect: a robot stutters when a colleague pushes a Docker image; the inference server's tail latency doubles when somebody joins the Wi-Fi; gradient sync to your fine-tune box mysteriously sees 200 ms spikes during the lunch rush. Get it right and the network stays invisible, which is the only thing you want from it.

This article is about the right shape for that network in 2026. Audience: integrators and lab builders standing up the "lab in a box" — one to four robots, one or two K-AI inference servers, a few dev workstations, and the storage and management bits that tie them together. Not a hyperscaler reference architecture. Not a homelab budget build. The actual middle.

The "lab in a box" target

The reference deployment for this article:

• 1–4 robots — humanoids, quadrupeds, or a mix. Wi-Fi 6E primary, optional wired tether during dev.
• 1–2 K-AI inference servers — 4× or 8× GPU (5090 / RTX Pro 6000 Blackwell), running vLLM / SGLang for VLMs and LLMs.
• 1–2 storage / NAS boxes — datasets, checkpoints, recorded sensor logs. Usually one ZFS box with NVMe cache.
• 2–6 dev workstations — engineers running ROS 2, Isaac Sim, training fine-tunes, copying data around.
• Management plane — IPMI/BMC on every server, switches, APs, a local DNS/DHCP host.

Total: 15–40 active network devices. A single switch could carry it electrically. The reason there are two switches in the design below is not capacity — it is fault domain, PoE budget, and the desire to keep robot traffic and GPU traffic on different physical wires so one cannot starve the other.

Physical topology

Two physical switches, one firewall, one or two APs. K-AI servers land on the core at 25 GbE; access switch aggregates workstations and APs; robots connect over dedicated 6 GHz SSID.

Two physical switches, one firewall, one or two APs. The K-AI servers and the storage box land on the core switch at 25 GbE. The access switch picks up the wired-but-slower devices — workstations, APs, IPMI, cameras — and uplinks to the core at 10 GbE. Robots come in over Wi-Fi 6E on a dedicated SSID.

Why 25 GbE between core and K-AI? Because the ConnectX-6 Lx dual-port SFP28 NIC is the cheapest credible card in 2026 (€700–€900 street, sometimes less on used) and 25 GbE is more than enough for single-server inference fan-in. A 70B Q4 model streaming tokens to four robots at once is in the tens-of-Mbit/s range. A model checkpoint shuffle is the bandwidth event of the day, and 25 GbE clears 100 GB in ~35 seconds. Customers running multi-node training need 100 GbE — covered in N01 and N08 — but that is a different network than the one in this article.

Speed tier sizing

Two things to internalise:

• You do not need 100 GbE in a single-server lab. People spec it because the data sheet looks impressive. The K-AI server's actual sustained network rate is "tokens out" (Mbit/s) plus occasional checkpoint shuffles (single-digit Gb/s). The wire is never the bottleneck on an inference-only lab.
• Wi-Fi is always the slowest hop. Plan around it. A good 6 GHz link to a Wi-Fi 6E client gets 1.2–1.8 Gb/s real throughput at 10 m line-of-sight, with 3–8 ms latency, jitter ±2 ms under decent conditions. Robot sensor streams (one or two RGB-D cameras at 1080p30 each) need ~150–300 Mb/s sustained; you have plenty of headroom — until somebody else joins the SSID.

VLAN segmentation

The reason this network has six VLANs is not corporate hygiene. It is so that one device's misbehaviour cannot ruin another's day.

The split that catches people: robots and K-AI are on different VLANs even though they constantly talk to each other. Inter-VLAN routing is the firewall/router's job, and it is the place to enforce who-can-talk-to-whom. If robots and K-AI shared a VLAN, a compromised robot (and consumer humanoids ship with attack surface) would have flat L2 access to the GPU server. That is a hard "no" in any half-serious deployment.

The other split worth defending: management plane is its own VLAN, full stop. IPMI/BMC interfaces have shipped with vendor backdoors for two decades and you should assume they always will. They get their own subnet, their own access rules, and nobody routes to them except an admin laptop on the management VLAN.

Firewall rules

Default deny between VLANs. Then exceptions:

Two opinionated rules worth flagging:

• Robots get no internet egress. People resist this because it breaks the manufacturer's telemetry / firmware update flow. Good. Whitelist the specific manufacturer update server on a maintenance window, then close it again. The default state is "this robot cannot phone home."
• K-AI WAN egress is on-demand. During a model download or container pull, open 443. Otherwise keep it closed. The inference server has no business browsing the web, and you do not want a curious developer's curl script being the path a worm uses to exfiltrate your dataset.

Wi-Fi setup

The single most common mistake in a robotics lab Wi-Fi build is "let's just put the robots on the office SSID." That SSID is shared with phones, laptops, printers, a smart fridge, and three people on Teams calls. Latency variance is brutal and the robot's reactive behaviour falls apart.

The right answer:

• One SSID per VLAN. "lab-robots" on VLAN 10, "lab-dev" on VLAN 30, "lab-guest" on VLAN 99. The mgmt VLAN has no wireless presence.
• The robotics SSID is 6 GHz only. No 2.4 GHz, no 5 GHz fallback. Yes, this means older devices cannot join — that is the point. 6 GHz has dramatically less contention because the legacy device population on it is essentially zero in 2026.
• Channel width 80 MHz, not 160. 160 MHz looks better on the data sheet, but two 160 MHz APs in the same building stomp on each other. 80 MHz at 6 GHz gives you four to six clean channels and predictable latency.
• One AP per ~60–80 m² of robot working area, line-of-sight if possible. If the lab has walls, add an AP. Roaming is fine on Wi-Fi 6E with 802.11r/k/v turned on, but a robot mid-task does not appreciate a roam event.
• Disable airtime fairness for the robot SSID. The default favours slower clients; you want the robot, which is the only consumer of that SSID, to get every airtime slot.

For 2026 hardware: UniFi U6 Enterprise (Wi-Fi 6E, ~€450) or the newer U7 Pro / E7 (Wi-Fi 7, €189 / €499+) are the cost-effective picks. Aruba 650-series and Cisco Meraki MR series are the enterprise-class alternatives at 2–3× the price; the management plane is nicer and the radios are better at high client density, neither of which a single-lab deployment with two robots actually needs.

Time sync — PTP and NTP

Clock drift between robot and server breaks sensor fusion in subtle and embarrassing ways. A 20 ms skew makes a stereo depth pipeline produce ghost objects. A 100 ms skew makes the manipulation planner think the gripper is somewhere it is not.

Two tiers of solution:

• NTP with chronyd against a local stratum-1 server (a Raspberry Pi with a GPS hat, ~€80 all-in, or the firewall acting as a stratum-2). Reaches ~1 ms accuracy on a wired LAN, ~5–20 ms over Wi-Fi. Adequate for most robotics work.
• PTP (IEEE 1588v2) with hardware timestamping on switches that support it. MikroTik CRS3xx/CRS5xx series support PTP boundary clock with nanosecond-range sync; Aruba CX 6300 and Cisco Catalyst handle it too. Reaches sub-microsecond on wired paths, sub-millisecond over Wi-Fi.

For 1–2 robots, NTP is fine. Run chronyd on every node, point it at the local master, monitor offset, alarm at >5 ms drift. For four-plus robots or any deployment doing multi-sensor fusion across machines, run PTP on the wired side and use NTP as a fallback. Either way, monitor the drift. The number of labs that "have time sync" because they ran apt install ntp once two years ago is large.

DNS, DHCP, and IPAM

Local resolver on the management plane, period. Pi-hole or Unbound on a small VM does the job. The reasons:

1. Robots and inference servers need to resolve vllm.lab.local, nas.lab.local, etc. without a round trip to the WAN.
2. You want one place to add a hosts entry when you spin up a new K-AI endpoint.
3. Pi-hole gives you a free network-wide ad/telemetry block, which keeps stray manufacturer phone-home traffic off your wires.

DHCP per VLAN, configured on the firewall/router (UDM Pro Max, OPNsense, pfSense all do this competently). Reservations for everything that matters — robots, servers, APs, IPMI, switches, NAS. Dynamic pools are for visitors and ephemeral workstations only. A robot that gets a different IP every reboot is a robot whose ROS 2 launch files break every Tuesday.

Monitoring

A lab without monitoring is a lab where problems are diagnosed by their consequences. Run the standard stack on the management plane:

• Prometheus scraping switch SNMPv3, NIC counters (node_exporter), GPU metrics (dcgm_exporter), and inference server metrics (vLLM exposes Prometheus natively).
• Grafana dashboards: per-port utilisation, per-VLAN throughput, GPU temp and utilisation, PTP/NTP drift, robot connectivity uptime.
• Alerts that actually fire: PFC pause counter > 0 on any port (means somebody is congesting RDMA, which you should not have on this network but check anyway), GPU temp > 80 °C, time drift > 5 ms, AP client count anomaly.

SNMPv3, not v2c. The lab is small enough that the marginal config work is fifteen minutes and the marginal security is real.

Concrete BOM — 1 server, 2 robots, 4 workstations

A working, honestly-priced shopping list for the reference deployment, mid-2026 EUR ex VAT:

For comparison: the 8-GPU K-AI server alone is €40–70k, the two humanoids are €30–80k each. The network is 5–10% of the total spend, and it is the part most likely to be the difference between a lab that works and one that does not.

If budget is tight, the credible cuts: drop the core switch to a MikroTik CRS504-4XQ-IN (4× QSFP28, breakouts to 16× 25 GbE, ~€700) and accept the smaller port count; use a single AP if the working area is <60 m²; skip the GPS NTP source and live with chrony over the WAN.

Common screw-ups

In rough order of how often each bites:

• Mixing robotics traffic with general office Wi-Fi. Latency variance kills reactive behaviour. The first fix on every "my robot is glitchy" call is "give it its own SSID on 6 GHz."
• Undersized buffers on cheap switches. A €200 8-port 10G switch handles two devices fine and falls over when four nodes hit the same uplink. AI traffic is bursty; switch buffers absorb the burst. The cheapest credible deep-buffer switch in this article is the Aruba CX 6300 (8/16/32 MB shared buffer); the MikroTik CRS5xx is shallower but enough for a single-server lab.
• No PTP master, no NTP audit. Time syncs "work" until they don't, and sensor fusion fails silently in between. Monitor offset and alarm.
• PoE budget miscalculated. A switch advertises "PoE++" and you discover its total budget is 200 W, half of which is consumed by the cameras nobody told you about, and the AP brown-outs at boot. Add the wattages, leave 30% headroom.
• Robot allowed to phone home. Manufacturer firmware update on a Tuesday morning, which downloads a new model, which changes the on-board inference latency, which breaks the gripper timing. Every time. Firewall the robot's WAN egress; control updates manually.
• No monitoring until something breaks. The lab works fine for six months. Then the AP starts dropping clients twice a day and nobody notices for a week because there are no dashboards. By the time someone digs in, four other things have changed and nobody can tell what failed first.

Honest take

Most robotics labs over-engineer their network and under-engineer the parts that matter. People spec 100 GbE backbones for single-server inference labs, then put the robot on the office Wi-Fi. They buy a Cisco Catalyst 9300X with deep buffers, then run flat L2 with no VLAN segmentation.

The 80/20 design for a 2026 single-server, 1–4 robot lab is small and unsexy:

• 25 GbE between core switch and the K-AI server. One NIC, one DAC, done.
• 10 GbE between core and access. Two DACs.
• One core switch, one access switch, one firewall, one or two APs.
• Six VLANs, default-deny firewall, separate SSIDs per role.
• NTP from a local source, monitored.
• Prometheus + Grafana on a small VM.

Total network spend: under €7k. Total time to commission: about a week if the cabling is ready. This carries a real production lab; the next step up — 100 GbE backbone, routed Clos, deep-buffer AI switches — is for multi-server training, which is the territory of N04, N08, and K02.

---

This is part of the Kentino Wiki, a reference series on AI compute, robotics, and the systems that connect them. Comments and corrections welcome at info@kentino.com.