Art-Net network design: unicast vs broadcast, IP addressing and switches

Art-Net runs happily on almost any Ethernet network at small scale, which is exactly why it bites people at large scale: the default behaviour that makes a 4-universe rig plug-and-play (broadcast) is the same behaviour that brings a 200-universe rig to its knees. This article covers designing the network itself: broadcast vs unicast, IP addressing, switch selection, and where the real limits are. For protocol fundamentals, start with our Art-Net overview; if you are still deciding between protocols, read Art-Net vs sACN.

Why classic Art-Net broadcast floods every port

An Ethernet switch normally works like a mail sorter: it learns which device is on which port and delivers each packet only to the port where the addressee lives. That sorting only works for unicast traffic, addressed to one specific device. A broadcast packet is addressed to "everyone on this network", and a switch has no choice but to copy it out of every port.

The original Art-Net (Art-Net I, 1998) sent ArtDmx packets as UDP broadcast, and many controllers and nodes still default to it because it requires zero configuration: the controller shouts every universe onto the wire and each node picks out the universes it has been patched to. The cost:

• Aggregate load becomes per-port load. With unicast, a node outputting 2 universes receives 2 universes of traffic. With broadcast, it receives the entire rig, and so does every other device on the subnet.
• Every node processes every packet in software. Filtering by universe happens inside the node's CPU, after the packet has already crossed the wire. A small microcontroller-based gateway hits its packet-processing ceiling well before the cable is anywhere near full, and it shows up as dropped frames and stuttering fades on nodes that look lightly loaded on paper.

The arithmetic: one universe is small, hundreds are not

One universe of Art-Net is genuinely small. An ArtDmx packet carrying a full universe is 530 bytes of UDP payload (an 18-byte Art-Net header plus 512 channel slots); with UDP, IP and Ethernet framing that is around 4,800 bits on the wire per packet. At the DMX-line-rate-matched refresh of 44 Hz, that is roughly 0.21 Mbit/s per universe. ENTTEC's own wired-network measurements (ELM outputting with ArtSync enabled and frame optimisation off, captured with Wireshark) came in at about 0.31 Mbit/s per universe at 60 frames per second, consistent once sync packets and the higher frame rate are included. The full test methodology and a downloadable calculator are in Networking: Bandwidth Planning.

Scale that honestly:

• 8 universes at 44 Hz: under 2 Mbit/s. Irrelevant on any modern network, even broadcast.
• 40 universes: roughly 8 to 12 Mbit/s. Fine on gigabit, but under broadcast that full load now arrives at every single port, including any 100 Mbit nodes, and every node is header-inspecting 1,700+ packets per second.
• 400 universes: on the order of 85 to 120 Mbit/s. Under broadcast that saturates every 100 Mbit port on the network outright, and even gigabit nodes are parsing 17,000+ packets per second each just to discard most of them.

The wire is rarely the first casualty; node CPUs are. Guidance originating with Artistic Licence (authors of the Art-Net specification) puts the practical ceiling for broadcast operation at around 40 universes; treat that as an upper bound, not a target. Exactly where broadcast becomes visible depends on your slowest node's processor, not on the switch.

This matters more than it used to because universe counts have exploded. A console rig might be 4 to 16 universes; pixel mapping is a different world. ENTTEC's ELM pixel mapping software can output hundreds of universes from one computer (the installer is free to download; the licence you run sets how many universes it can output, and full licences come bundled with ENTTEC pixel controllers), and at that scale broadcast is not viable.

Unicast: the fix, and what it demands

Since Art-Net II (2006), controllers are expected to discover nodes via ArtPoll/ArtPollReply and then send each ArtDmx packet only to the node subscribed to that universe. The switch goes back to being a mail sorter, per-port load drops to what each node actually consumes, and hundreds of universes become routine on ordinary gigabit hardware. It is the single biggest lever in Art-Net network design, but it is not free. It demands:

• A deliberate IP plan. Every node needs a known, stable, unique address on the same subnet as the controller: static IPs, or DHCP reservations. Duplicated IPs, which broadcast quietly tolerates, break unicast immediately, and a node that changes address goes dark until the controller is updated.
• A controller that actually unicasts. Most modern consoles and software (including ELM and EMU; both are free to download, though EMU's free tier outputs a single universe, which suits bench testing rather than large rigs) and current ENTTEC gateways such as the ODE MK3, Storm 10 and DIN Ethergate MK2 support it, but it is often a per-output setting that defaults to broadcast for compatibility. Check it; "it worked in the shop with two nodes on broadcast" is how large rigs get commissioned wrong.
• Headroom at the controller's own port. Unicast concentrates traffic at the source: the controller's port carries everything it sends, and a universe mirrored to 20 nodes costs 20 packets per frame. On gigabit this is rarely a problem, but it is why the controller should always be on a gigabit link, and one-to-many distribution is the one workload where sACN multicast is structurally better; see Art-Net vs sACN.

Even a fully unicast rig still uses a little broadcast: ArtPoll discovery packets are broadcast by design, but they are tiny and infrequent. Per-node IP and universe configuration is covered step by step in setting up an Art-Net to DMX node.

IP addressing: the 2.x.x.x convention vs plain private ranges

The Art-Net specification defines a self-addressing scheme: nodes generate an address in 2.x.x.x (or 10.x.x.x as a secondary option) with a 255.0.0.0 netmask, derived from the device's MAC address. The convention exists because Art-Net predates the assumption of a DHCP server on every network: it let a box of nodes come up with statistically unique addresses on an isolated lighting LAN with no configuration at all.

Both the convention and plain private addressing work, and Art-Net itself does not care which you use. The trade-offs:

• 2.x.x.x is fine on a fully isolated lighting network, but 2.0.0.0/8 is publicly allocated internet address space. If that network ever gains a route to the internet, or a laptop bridges it to another interface, you get address conflicts with real public hosts. Treat 2.x.x.x as isolated-network-only.
• 10.x.x.x is RFC 1918 private space, so it is safe everywhere and still satisfies the Art-Net convention. This is our default recommendation: something like 10.0.x.y with a documented allocation (for example, controllers in 10.0.0.x, nodes in 10.0.1.x) and static addresses on every node.
• 192.168.x.x with DHCP works for temporary setups, but DHCP-assigned node addresses can change between power cycles, silently breaking unicast patching. If you use DHCP, use reservations.

Whatever range you pick, keep the controller and all nodes in one subnet with the same mask, write the scheme down, and change your computer's address to match: see our guides for Windows and macOS.

Choosing switches without the folklore

For a unicast Art-Net rig, an unmanaged gigabit switch from any reputable vendor is genuinely fine. Modern unmanaged switches are wire-speed devices; there is no hidden "pro" quality tier that Art-Net needs. Spend the money on cabling and spares first. Managed switches earn their cost for specific reasons:

• IGMP snooping and an IGMP querier, which matter for sACN multicast, not for Art-Net unicast. Without them, multicast degrades to flooding and you inherit exactly the broadcast problem you were avoiding. Details in sACN Multicasting & IGMP.
• VLANs, to isolate lighting traffic from house IT, guest WiFi, Dante audio or video-over-IP on shared infrastructure.
• Diagnostics. Per-port traffic and error counters turn "the rig is glitching" from guesswork into a five-minute investigation.

Practical cautions for any switch class: prefer gigabit ports throughout (100 Mbit ports are where broadcast floods bite first); disable Energy Efficient Ethernet (EEE, 802.3az) where the option exists, because its power-state transitions can add latency jitter to steady low-rate streams; and do not use a domestic WiFi router's LAN ports as your show switch, since its DHCP server and WiFi bridging will interfere with a deliberately addressed network. If you are linking multiple switches, read Networking: Chaining Network Devices first, because uplinks concentrate traffic that per-port arithmetic hides.

Sharing a network with audio and media systems

The clean rule is that lighting gets its own network. Broadcast Art-Net on a converged network will hit every Dante interface, media server NIC, printer and office PC on the subnet; conversely, a house network's chatter, DHCP server and security scanning can disrupt your nodes. If physical separation (a dedicated switch and cabling) is not possible, use a managed switch to put lighting on its own VLAN, a logically separate network carried on the same hardware. Dante and most media protocols want the same isolation for their own reasons, so this is rarely a hard sell. Do the bandwidth arithmetic per VLAN, run unicast only on shared infrastructure, and keep broadcast-mode devices off it entirely.

WiFi: the honest position

WiFi is a shared, half-duplex medium with retransmissions and unpredictable latency, and broadcast frames over WiFi are sent at low legacy data rates without acknowledgement. It can carry a few universes for a walkaround focus session, and it will fail unpredictably in crowded RF environments. We do not recommend it for show-critical output, and no amount of network design changes that. The full reasoning and mitigations are in Sending over WiFi.

Sizing rules of thumb

Figures assume 44 Hz refresh and the measured rates above; treat them as planning guides, and always leave headroom.

These boundaries are deliberately conservative: broadcast degrades gradually, starting at your slowest node.

How it looks when it falls over

Overloaded Art-Net networks rarely fail cleanly. The symptoms are jerky fades and stepped movement (dropped frames), nodes whose web interfaces stop responding while output continues, fixtures freezing on the last received value, and problems that appear only under full-rig output and vanish on the bench. If your fades stutter despite the numbers saying you have headroom, check whether the controller is still in broadcast mode, look for a duplicated IP, check the uplinks between switches, and then work through Art-Net/sACN Troubleshooting.