Track 01 · Networking

A network you can trace, shape and rebuild.

Consumer routers hide everything behind a glossy app; enterprise kit hides it behind a licence. The open path sits in between: OpenWrt on replaceable hardware, standard routing daemons, WireGuard where the link is untrusted, and queue management that keeps latency low while the link is saturated.

WAN / fibre router switch AP server AP vlan 20 · wireless vlan 30 · services
Segmented, documented, and every hop is something you can log into.
OpenWrtFirmware baseline
WireGuardIn-kernel since 5.6
CAKELatency under load
BGPFRR or BIRD

Principles

Four rules that keep a network yours

Everything below follows from these. When a product violates one of them, we look for another product.

Rule 01

Firmware you can flash

Prefer hardware with a supported OpenWrt target, documented recovery mode and a serial header. If you cannot get back in after a bad image, it is not yours.

Rule 02

Addressing you can say aloud

One plan, written down, applied everywhere. VLAN per trust level, not per device. Static where it is infrastructure, DHCP with reservations for everything else.

Rule 03

Latency is a feature

Throughput benchmarks hide queueing. Shape the uplink with CAKE so a large upload does not turn a video call into a slideshow.

Rule 04

Assume the link is hostile

Encrypt across any network you do not own. Overlay routing between sites beats trusting a hotel, a venue or a carrier CPE.

Open hardware

Routers, switches and radios you actually own

Networking is where open hardware pays off fastest: a router is a small computer, and a small computer with published schematics, a mainline kernel target and a recovery header can stay in service for a decade. The alternative is a sealed box that stops receiving updates while it is still perfectly capable of routing packets.

Board

OpenWrt One

The first router board designed by the OpenWrt project itself, built with Banana Pi. Published design, a mainline OpenWrt target, and recovery designed in so a bad image is an inconvenience rather than a brick.

Board

Turris Omnia & MOX

Open hardware from CZ.NIC with an OpenWrt-based system, automatic signed updates and a modular layout. You can move the radios to a different position than the CPU, which is a genuine engineering advantage.

Board

PC Engines APU

Fanless x86 with published schematics, coreboot firmware and multiple independent NICs. No Wi-Fi and no case included, which is exactly why it is a good router rather than a good appliance.

Board

Banana Pi & NanoPi class SBCs

Dual and triple Ethernet single-board routers with published designs. Excellent value, provided you confirm the kernel version and how many firmware blobs a given board actually needs before you commit.

Radio

Open wireless

Prefer radios with open drivers — mt76 and the ath family — and be aware that many Wi-Fi chips need a firmware blob. Fully blob-free operation is possible, but check the model, not the brand.

Datacentre

OCP switches with SONiC

Open Compute Project switch designs paired with open network operating systems. Loud, deep and power-hungry, but a real switch you can rebuild and reflash instead of a sealed appliance.

Platforms we would deploy, with the trade-off stated plainly. Availability and support change — verify the current state before buying.
PlatformClassHow openThe catch
OpenWrt One Wi-Fi 6 router board Published design, mainline target, recovery built in Two ports; it routes, it is not a switch
Turris Omnia / MOX Wi-Fi router / modular node Open hardware, open OS, signed automatic updates Higher price, limited regional supply
PC Engines APU Fanless x86 router Schematics published, coreboot, three GbE ports No Wi-Fi, no case, needs a radio card
Banana Pi BPI-R3 / R4 SBC router Design files published, mainline support varies by revision Confirm blob count and kernel support for your revision
LibreRouter Outdoor mesh node Open hardware plus LibreMesh firmware Low-volume supply; plan spares
Wedge / Edgecore with SONiC Datacentre switch OCP hardware, open network OS Noisy, deep, drawn from a different league of power
Intel i210, Mellanox ConnectX Server NIC Free drivers in mainline, public datasheets Auction-site cards are frequently counterfeit

Six questions before you buy any network hardware

1. Are the schematics published? 2. Is there a mainline kernel or OpenWrt target, and which version? 3. How many firmware blobs does it need, and for what? 4. Can you reach a recovery console without a proprietary tool? 5. Does the vendor still ship security updates, with a verifiable policy? 6. Will the optical or PoE ports accept third-party modules, or is there an EEPROM allow-list?

Reference build

The quiet network closet

A fanless x86 or ARM router, a managed switch with PoE, a UPS that reports its own state, and a patch panel with labels that survive a decade. This is the smallest setup that still lets you segment traffic, run services and survive an outage.

  1. Choose the router by its NICs

    Two or more independent network interfaces, a supported OpenWrt target, and enough RAM for your routing table. Avoid USB Ethernet for the WAN side.

  2. Segment before you connect anything

    Define the VLANs first — management, trusted, wireless, services, guests. The switch configuration is a consequence of the plan, never the other way around.

  3. Label both ends of every cable

    Same identifier at patch panel and device. Document the port map in the repository, not on a sticky note on the rack door.

  4. Make the UPS visible

    Connect the UPS over USB and expose it to your monitoring. An outage you learn about from the graph is an outage you can explain.

  5. Back up the config, then restore it once

    A backup you have never restored is a hypothesis. Wipe the router, restore the archive, confirm the network comes back.

Closet checklist

  • Power — one circuit, surge protection, UPS with USB reporting.
  • Thermal — fanless where possible; if it has a fan, filter it and log its RPM.
  • Cabling — solid-core for permanent runs, stranded for patches, never bend tighter than four times the cable diameter.
  • Labelling — printed, not handwritten; both ends; a port map in version control.
  • Out-of-band access — a serial console or a physically separate management path.
  • Documentation — the addressing plan, the firewall policy and the recovery procedure.

Hardware to avoid

Anything that requires a cloud account to complete setup, any router whose recovery path is a proprietary Windows utility, and switches that cannot report per-port counters over SNMP or a documented API.

Planning

An addressing plan you can memorise

Use a private range wide enough for room to grow, and encode meaning in the third octet. The example below assumes 10.20.0.0/16 as the site prefix.

Example VLAN and prefix plan. Adapt the numbers, keep the structure.
VLANNamePrefixGatewayWhat lives here
10mgmt10.20.10.0/24.1Switch, router, UPS, BMCs — no internet except updates
20trusted10.20.20.0/24.1Workstations and laptops you administer
30services10.20.30.0/24.1Servers, NAS, backups, monitoring
40wireless10.20.40.0/24.1Phones, TVs, appliances — treated as untrusted
50studio10.20.50.0/24.1Audio and video endpoints needing stable latency
99guest10.20.99.0/24.1Visitors, isolated, rate-limited
transit10.20.255.0/30Point-to-point links and overlay endpoints

Write the plan down before the first cable

A one-page text file in version control beats an evening of guessing which address is free. Include the DHCP reservation list, the firewall intent per VLAN, and the date you last verified that the running configuration matches the document.

Budgeting

Know where your milliseconds go

Latency budgets are how you decide whether a problem is the network's fault. Measure each hop, write the number down, and compare against the budget instead of against a feeling. The figures below are typical orders of magnitude, not promises.

Indicative one-way contributions. Actual values depend on hardware, load and distance.
SegmentTypical added latencyDominant cause
Wired LAN, idleunder 0.3 msSwitch store-and-forward
Wired LAN, saturated1–20 msBufferbloat without shaping
Wi-Fi, good signal2–8 msContention and retries
WireGuard over WAN0.5–3 msCPU encryption cost
Metro fibre1–5 msPropagation plus switching
Cross-continent60–150 msSpeed of light in glass

Configuration

Two snippets worth memorising

WireGuard peer

# /etc/config/network (OpenWrt) — overlay between two sites
config interface 'wg0'
    option proto 'wireguard'
    option private_key 'REDACTED'
    option listen_port '51820'
    list addresses '10.20.255.1/30'
    option mtu '1420'

config wireguard_wg0
    option description 'site-b'
    option public_key 'REDACTED'
    option route_allowed_ips '1'
    list allowed_ips '10.20.255.2/32'
    list allowed_ips '10.21.0.0/16'
    option persistent_keepalive '25'

Keep MTU below the tunnel overhead; 1420 is a safe starting point on a 1500-byte path. Persistent keepalive is only needed behind NAT on one side.

Shaping with CAKE

# Keep the uplink responsive while saturated.
# Set the bandwidth to ~85-95% of the measured uplink.
tc qdisc replace dev eth0 root cake \
    bandwidth 90Mbit \
    dual-dsthost dual-srchost \
    nat \
    diffserv4 \
    ack-filter

# Verify what the kernel actually installed:
tc -s qdisc show dev eth0

Shaping only helps on the bottleneck link you control. Shape the uplink on your router and, if your ISP supports it, borrow their downstream shaper via RFC 8289-style tags or a supported AQM profile.

Open audio over IP

Carry audio across the network without a licence fee

Audio over IP is the place where the networking and sound tracks meet. The good news is that the open route exists and interoperates: AES67 describes how to move uncompressed audio in RTP with PTP clocking, and open implementations are available on Linux today. The catch is that networked audio is unforgiving — clocking, latency and multicast are not optional refinements, they are the whole problem.

Approaches to audio and media over a network, from fully open standards to proprietary ecosystems with an escape hatch.
Approach Status Clocking Open implementation Best for
AES67 Open interoperability standard PTP, IEEE 1588 PipeWire RTP modules, module-rtp-sap Mixing brands of professional gear on one wire
RAVENNA RTP-based, AES67-compatible PTP Reached from Linux through AES67 mode Broadcast, high channel counts
AVB / Milan Open IEEE 802.1 standards with TSN gPTP, IEEE 802.1AS Partial Linux support; needs AVB-capable NIC and switch Deterministic layer 2 in installed venues
Dante Proprietary ecosystem Vendor PTP profile None; interop only where a device offers AES67 mode The commercial default — plan an exit path
NetJack JACK-specific, not a standard JACK transport jackd -d net, GPL A quick LAN link between two JACK machines
Snapcast Open, purpose-built NTP-style sync GPL server and clients Multiroom playback, not low-latency work
SRT Open protocol, MPL-2.0 Timestamps, retransmission libsrt, FFmpeg, GStreamer Contribution over a lossy WAN link
RTP-MIDI Open standard, RFC 6295 Session timestamps rtpMIDI, jackrtpmidi Control and MIDI across the network
NDI Proprietary SDK Not applicable No open implementation of the core Video-first workflows where the ecosystem decides

Method

Five things that decide whether it works

  1. One clock master, everything else slaved

    PTP provides the reference; do not let every device free-run and hope. If your audio hardware also has a word-clock input, keep that hierarchy consistent with the PTP hierarchy instead of creating two competing authorities.

  2. Hardware timestamping on the NIC

    Software timestamping adds jitter that no buffer setting can remove. Check with ethtool -T and pick a NIC that reports hardware transmit and receive timestamping.

  3. Its own VLAN and a DSCP class

    Put audio in a dedicated VLAN, mark it DSCP EF, and make the switch trust those markings. Never let a backup job share a queue with a live stream.

  4. A stated latency target

    AES67 is comfortable at about 1 ms of network latency at 48 kHz — 48 samples per channel — and many devices also offer 125 µs to 250 µs packet times. Decide the target, then size buffers to meet it rather than guessing.

  5. Measure the round trip

    Use a loopback measurement, not your ears. jack_iodelay reports actual round-trip latency, and pw-top shows whether the graph is keeping up or quietly dropping cycles.

Configuration

PTP and an AES67 stream from a desktop

# Clocking. One grandmaster, everyone else slave-only.
ptp4l -i eno1 -f /etc/ptp4l.conf -m      # grandmaster
ptp4l -i eno1 -s -m                      # slaves: -s = slave only
phc2sys -s eno1 -c CLOCK_REALTIME -w -m  # align the system clock

# Confirm the NIC timestamps in hardware, not in software.
ethtool -T eno1

# Energy-efficient Ethernet adds latency and drops packets.
ethtool --set-eee eno1 eee off
# ~/.config/pipewire/pipewire.conf.d/20-aes67.conf
# Argument names have changed between PipeWire releases —
# check the module documentation for the version you run.
context.modules = [
  { name = libpipewire-module-rtp-sap
      args = {
        local.ifname        = "eno1"
        sap.ip              = "239.255.255.255"
        sap.port            = 9875
        net.mtu             = 1500
        sess.latency.msec   = 1
        audio.format        = "S24LE"
        audio.rate          = 48000
        audio.channels      = 8
        source.ip           = "10.20.50.10"
        source.props = {
          node.name        = "aes67-output"
          node.description = "AES67 8-channel output"
        }
      }
  }
]

Restart the PipeWire daemon, then confirm the node appears with pw-link -o or pw-cli ls Node. If the stream is silent, check multicast group membership and the switch's IGMP snooping configuration before touching the audio settings.

Interoperating with a proprietary install

You rarely get to choose the whole ecosystem. Many commercial audio-over-IP devices offer an AES67 mode precisely so they can be bridged, which makes the open standard your practical escape hatch: keep the proprietary gear where it already is, and bring your own machines in over AES67 rather than buying into a parallel proprietary stack. Document the mode, the latency setting and the clock role for each device, because that configuration is exactly what gets forgotten after a firmware update.

Toolchain

Software we actually deploy

All of it is open source, packaged by mainstream distributions, and replaceable.

OpenWrt

A full Linux distribution for routers, with an image builder for reproducible firmware. Config lives in text files, so the whole router is version-controllable.

FRR & BIRD

Routing daemons that speak BGP, OSPF and IS-IS the same way the big routers do. Useful the moment you have a second uplink or a second site.

WireGuard

Small, fast, auditable, and in the mainline kernel since 5.6. Route-based tunnels mean you use the ordinary Linux routing table instead of a custom stack.

CAKE & fq_codel

Queue management that keeps latency bounded under load. One line of tc fixes the most common complaint about home and studio uplinks.

BATMAN-adv & 802.11s

Layer-2 mesh for buildings where cabling is impossible. Design for wired backhaul first; treat wireless backhaul as the compromise it is.

Prometheus & Grafana

Scrape SNMP and node exporters, alert on what matters: link errors, queue drops, UPS on battery, certificate expiry.

Errata and honesty notes

Wireless throughput claims are almost always measured under ideal conditions with a single client. Treat marketing numbers as a ceiling, expect roughly half in a real building, and measure your own environment before designing around a figure. Likewise, a VPN adds CPU load: on a small router, run a throughput test with the tunnel up before you commit to routing all traffic through it.

Next

Networks carry audio and pixels too

Once the transport behaves, the interesting problems move up the stack: keeping clocks aligned for audio, and keeping colour consistent for graphics.