showstack

Question one

Why does QoS matter more here than in an office?

In an office, a late packet is a slower file. On a show network, a late packet can be a clock. Dante, AES67 and ST 2110 all lock their devices to a shared PTP reference, and PTP works by measuring how long messages take to arrive. Delay a clock message behind a big file copy and the receiver does not just get the time late — it calculates the wrong time.

That is why audio-over-IP fails the way it does: not gracefully, not gradually, but as clicks and dropouts on a network whose bandwidth graph looks fine. The link was never full. One queue was, for a few milliseconds, at the wrong moment.

Quality of Service is the switch being told which packets to send first when it cannot send everything at once. Clock highest, media next, everything else last.

Question two

How do I calculate a subnet mask?

An IPv4 address is 32 bits. The mask does one job: it says how many of those bits from the left identify the network, leaving the rest to identify the host. That is the whole idea — /24 means "the first 24 bits are the network".

Everything else is arithmetic that falls out of it. Set the host bits to all zeros and you have the network address. Set them to all ones and you have the broadcast address. The number of hosts is two to the power of the host bits, minus two — one for the network address, one for the broadcast.

Drag the boundary below and watch it happen. The bits that turn teal are the network; the amber ones are what is left for devices.

Question three

Why does multicast need the switch’s help?

Multicast is how one sender reaches many receivers without sending a copy to each — the mechanism sACN, Dante and ST 2110 all rely on to scale past a handful of devices.

But a switch does not know who wants a given multicast group unless it is listening to the messages where devices subscribe. Without IGMP snooping, and an IGMP querier somewhere on the VLAN to prompt those messages, the switch does the only safe thing it can: it sends every multicast packet to every port.

On a small rig that is invisible. On a full lighting network it is every universe arriving at every device, including the laptop that just wanted to be on the wifi.

One model, four kinds of traffic

The Four Flows, and what kills each one

Everything on a show network is one of four things. That is the whole model, and it is worth more than any single protocol fact on this site, because it turns "what is this packet" into "what should I expect this switch to do to it".

The four are control, media, clock and management. Each has a character, and — this is the half that makes the model predictive rather than decorative — each has one specific thing that kills it.

Every protocol entry on this site names its flow, and says so before it gives you a single port number, because the flow is the frame the numbers sit in.

Why the model earns its keep

Because it predicts, rather than describes

A category tells you what a protocol is for. A flow tells you what it behaves like, and the two come apart more often than you would guess — which is exactly when the model is worth having.

RDM travels on the DMX pair and is filed with lighting control everywhere you look. Its flow is management: discovery and configuration, with no show deadline, competing with traffic that has one. That is precisely why RDM is scheduled into the gaps between lighting frames rather than alongside them — and the flow model predicts that, where the category does not.

RTP looks like plumbing and is filed under network transport. Its flow is media, because it is the thing AES67, RAVENNA and ST 2110 all actually ride on.

And some entries have no flow at all. PoE is power. RS-485 is a pair of wires and a voltage convention. Giving either a flow would be a guess in a fact’s clothing, so those entries say so and leave it blank.

First principles

Two addresses, because two different jobs

Everything above assumed you already knew what an address is, which is the kind of assumption that leaves people quietly stuck. So, plainly: every device on a network has two addresses, and the reason is that they answer two different questions.

A MAC address is burned into the network interface at the factory. Forty-eight bits, written as six hex pairs like 00:1D:C1:AA:BB:CC, and the first three pairs identify the manufacturer. It never changes and it means nothing about where the device is — it is a name, not a location. It only works within one local network segment, because the way anything finds a MAC address is by shouting on the local wire and waiting for an answer, and shouting does not cross a router.

An IP address is assigned, not born, and it encodes where. That is the whole reason it exists: because it has structure, a router can look at an address it has never seen and know which direction to send it. A MAC address gives you no such clue — there is no way to look at one and work out which continent it is on.

So the two work as a pair, at different scales. IP gets a packet across the world to the right network. MAC gets it across the last stretch of copper to the right socket. On every hop the MAC addresses are rewritten and the IP addresses are not, which is the single most useful thing to know when reading a packet capture.

Four numbers, or eight groups

IPv4, IPv6, and why anybody bothered

IPv4 is the familiar one: four numbers 0–255, which is 32 bits, which is about 4.3 billion addresses. That sounded limitless in 1981 and ran out around 2011, which is the entire reason IPv6 exists.

IPv6 is 128 bits, written as eight groups of four hex digits — 2001:0db8:0000:0000:0000:ff00:0042:8329 — with runs of zeros collapsed to :: once per address, so that becomes 2001:db8::ff00:42:8329. The address space is not four times bigger, it is 2⁹⁶ times bigger, which is a number with no useful comparison.

What changes in practice is smaller than the address length suggests. There is no broadcast in IPv6 — its jobs are done by multicast, which is tidier. Devices can configure their own addresses from the router’s advertisements without a DHCP server. Fragmentation is the sender’s problem rather than the router’s. And a device commonly holds several IPv6 addresses at once, including a link-local one starting fe80:: that always exists and never leaves the segment.

For show networks the honest position is that IPv4 is what nearly all entertainment protocols assume. sACN, Art-Net, Dante and most of the rest are specified and deployed on IPv4, several of them with multicast group addresses written into the standard. Turning IPv6 on alongside is usually harmless and occasionally useful; expecting it to replace IPv4 on a show network is not yet a plan.

Seven layers

Where each thing on this site actually sits

Every protocol indexed here lives somewhere in a stack, and knowing where saves a lot of pointless debugging. Physical wire at the bottom, meaning at the top.

One frame, read on the fly

Why EtherCAT is fast, and why it is not Ethernet as you know it

Ordinary Ethernet addresses one device at a time: a frame goes out, a device answers, the next frame goes out. EtherCAT sends a single frame past every device in the chain and each one reads its own slice and writes its reply as the frame passes through it, without stopping it. One frame serves the whole chain in one pass, which is why cycle times land in the tens of microseconds rather than the milliseconds.

The cost is that this is not a network in the ordinary sense. The devices are a chain, the order matters, and a standard switch in the middle breaks the mechanism entirely — which is the same bargain DMX makes, arrived at from the opposite direction.

One cable, several networks

What a VLAN actually does

A VLAN splits one physical switch into several logical ones. Ports in VLAN 10 can talk to each other and cannot reach ports in VLAN 20, even though they are in the same box on the same rack.

Mechanically it is four extra bytes. A tagged frame carries a 12-bit VLAN ID inserted into the Ethernet header — 802.1Q — so 4094 usable VLANs, and the switch reads the tag to decide where the frame is allowed to go. A port is either an access port, which belongs to one VLAN and sends untagged frames to a device that knows nothing about any of this, or a trunk, which carries several VLANs tagged and is how you get more than one network down a single cable between switches.

Why it matters on a show is that broadcast and multicast traffic stays inside its VLAN. Put lighting, audio and production on one flat network and every sACN packet reaches the audio gear, every Dante flow reaches the lighting nodes, and a single misconfigured device can flood all of it. Separate them and each one only has to survive its own traffic. It is also the cheapest form of security available: a laptop plugged into the wrong socket lands somewhere that cannot reach the show control network at all.

The catch is that VLANs cannot talk to each other without a router, and about half of all show-network confusion is somebody discovering this at exactly the wrong moment. If the console is in VLAN 10 and the media server is in VLAN 20, they are on different networks, and no amount of correct IP configuration will change that until something routes between them.

Two cables, one link

Aggregation, and what it does not do

Link aggregation — LAG, port channel, bonding, LACP, all roughly the same thing — makes several physical cables behave as one logical link. Two gigabit ports become a two-gigabit trunk with automatic failover if one cable is pulled.

The failover half is genuinely valuable and works as advertised. The bandwidth half needs a caveat that catches people out: aggregation does not give a single conversation more bandwidth. The switch chooses which physical link to use by hashing something about each flow — source and destination MAC, or IP, or port numbers — and every packet of one flow follows the same link, so packet order is preserved. A single 1.4 Gbit/s video stream across two 1 Gbit/s links does not work. It picks one link and drops the excess.

So aggregation buys you resilience always, and throughput only when the traffic is many independent flows. On a show network that is often exactly what you have — dozens of Dante flows, many sACN universes — and it is occasionally the opposite, which is when somebody discovers the hash. Most switches let you choose what to hash on, and moving from MAC-based to IP-and-port-based hashing is the usual fix for traffic that has all piled onto one link.

Watching and reaching

TAPs, mirrors and VPNs

Three more pieces of vocabulary that get used as though everyone already knows them.

A network TAP is a passive device spliced into a link that copies everything passing through it to a monitoring port. Passive is the point: it has no configuration, cannot drop traffic, and keeps working if it loses power, so it does not become the thing that broke the show. A port mirror or SPAN does the same job in software on the switch, which costs nothing and is fine for diagnosis — but a busy switch drops mirrored frames before it drops real ones, so a mirror can lie about exactly the congestion you are trying to investigate. If you are proving a timing problem, use a TAP.

A VPN builds an encrypted tunnel across a network you do not trust, so two things far apart behave as though they are on the same local network. On a show that usually means remote support: somebody at home reaching a console or a media server on site. It is the right tool for that and the wrong tool for anything time-critical, because a tunnel across the public internet inherits the internet’s latency and jitter, and no amount of QoS at your end governs what happens in the middle. Remote programming over VPN: yes. Live show traffic over VPN: no.

Private and public

Why a show network lives in numbers nobody can route to

Some address ranges are reserved and will never appear on the public internet. Routers along the way drop them, deliberately. Those are the private ranges, set aside by RFC 1918, and there are three: 10.0.0.0/8 with sixteen million addresses, 172.16.0.0/12 with a million, and 192.168.0.0/16 with sixty-five thousand.

A show network lives in one of them, and the reason is not tidiness. A private address cannot be reached from outside without something deliberately forwarding to it. That is a security property you get for free by choosing the right numbers, and it is why the first question about any device that turns out to be reachable from the internet is what address range it was on.

Which range to pick is mostly about collisions. 192.168.x.x is the default on nearly every consumer router, so it is the range most likely to clash when somebody brings a laptop, a travel router or a home habit onto site — two networks that both think they are 192.168.1.0/24 cannot be bridged without renumbering one of them. 10.x.x.x has room for VLANs and a sensible numbering scheme, which is why most permanent installations use it. 172.16 to 172.31 is the least used, and that is occasionally a reason to choose it.

Everything outside those ranges is public, which means somebody owns it. Assigning yourself a public address on a private network works perfectly until the day something on your network needs to reach the real owner of that address, at which point the traffic goes to your own kit instead and the fault makes no sense at all.

The browser cannot get there

Why no web page will ever talk to your rig directly

This one comes up constantly, usually as “there is a web tool that does this, why do we need a box?” The answer is a deliberate boundary rather than a missing feature, and it is worth knowing because it decides what a browser-based control surface can and cannot be.

There are two separate walls, and people usually only know about the first. A browser has no UDP socket and no raw TCP: fetch and WebSocket speak HTTP and WebSocket and nothing else, so no page can emit sACN, Art-Net, PJLink or anything else that is not those. That alone rules out most of this industry’s protocols.

The second wall is the interesting one. Even for the protocols a browser can speak, a page served from a public address is not allowed to reach a private one. A page on some public site cannot quietly open http://192.168.1.1 and reconfigure your router, or work through 192.168.1.0/24 looking for what answers. Browsers block that crossing on purpose — the mechanism is called Private Network Access, and it was previously CORS-RFC1918 — and a public page that tries gets refused before a packet is sent. Your private numbers being unroutable from outside is the point of them, as the section above says, and the browser is enforcing the same idea one layer up.

So the shapes that actually work are the ones you see in the field. Software that runs on the network, serving its own web interface from inside it — which is why a console’s remote is served by the console. A page loaded from the device itself, which is same-origin and private-to-private, so neither wall applies. A native application, which has real sockets. Or a page that does the thinking and hands the sending to something that can, which is what the packet builders do: the arithmetic happens in the browser, and the command it gives you runs on your machine, on your network, where there is no public-to-private hop to be blocked.

The useful test when somebody proposes a browser-based anything: where is the page served from, and where does the packet have to go? Same private network, and it is fine. Public site reaching into a private range, and it will not work, no matter how well written it is.

The addresses that are a diagnosis

What 169.254 and 127.0.0.1 are telling you

Several reserved ranges are not configuration at all — they are the network reporting a state, and reading them saves a great deal of time.

169.254.x.x is the one worth recognising instantly. It means DHCP failed and the device gave up and named itself — link-local, RFC 3927. A device on one of these can reach other devices that did the same thing on the same wire, and nothing else. It is not a working configuration that happens to look odd; it is a device saying it never got an address. The fix is upstream: no DHCP server, a cable in the wrong VLAN, or a server that ran out of leases.

127.x.x.x is loopback: the machine talking to itself, never leaving the network card. A service bound to 127.0.0.1 is unreachable from anywhere else however good the cable is, and a great deal of "it works on my machine" is exactly this.

224.0.0.0/4 is multicast — a group rather than a host. Nothing is assigned one; devices subscribe. sACN sits at 239.255.x.x, where the last two octets are the universe number, so 239.255.0.1 is universe 1 and you can read a capture without a lookup table.

And 100.64.0.0/10 is carrier-grade NAT: your internet provider sharing one public address across many customers. It behaves like a private range, it is not yours to use, and it is why some remote-access setups that work at home fail on a venue connection.

At the terminal

The commands, and what in the output actually answers the question

Nearly every network question on a show has a one-line answer from a terminal. The reason people do not use them is that the command has a different name on every platform and the output arrives unlabelled, so the useful part is not the command but knowing what to read.

Two are worth learning before the others. The route table — route print, netstat -rn, ip route — because a laptop connected to both the show network and wifi has two default routes, and traffic disappearing into the wrong interface is the single most common self-inflicted fault on a production network. And the multicast joins — netstat -g, ip maddr show — because a receiver that has not joined the group will never see the traffic however correctly it is being sent.

The distinction worth carrying from ping is between its two failures. “Destination host unreachable” is your machine giving up before anything left; a timeout means the packet left and nothing came back. Those are different faults in different places, and treating them as the same thing is how people end up replacing a working cable.

And from tracert: a hop showing stars has declined to answer, which is normal and not a fault. What matters is a hop where the time jumps, because that is the link doing the damage. The command reference on the tools page has all of them side by side, with what to look for in each.

Hiding who is talking

What a VPN does not do, and what onion routing does instead

A VPN encrypts your traffic and sends it to a server that forwards it on. That hides the content from the local network and hides your address from the far end — but the VPN operator can see both ends of every connection you make. It does not remove the need to trust somebody. It moves that trust from your café’s wifi to a company you have probably never met, which is sometimes a good trade and sometimes a worse one.

Onion routing — Tor is the well-known implementation — removes the single trusted party rather than relocating it. Your traffic is wrapped in three layers of encryption and passed through three relays chosen from thousands. The first relay peels one layer and knows who you are but not where you are going. The third peels the last and knows where you are going but not who you are. The middle one knows neither. No single relay ever holds both halves, which is the whole idea, and it is why it is called onion routing: layers, removed one at a time.

The cost is latency, and a great deal of it. Three hops chosen for diversity rather than proximity might route you through three continents, so round trips run into hundreds of milliseconds and vary constantly. That makes it completely unsuitable for anything on this site with a clock in it — no timecode, no PTP, no live media, no remote console control. It is a tool for reading and publishing, not for running a show.

Two refinements worth knowing. An onion service — a .onion address — has no exit relay at all, because both ends stay inside the network and meet at a rendezvous point; nothing ever emerges onto the ordinary internet, so there is no exit operator who can watch it. And what none of this hides is what you do: log into an account and you have identified yourself, whatever the transport did. Onion routing protects the metadata — who is talking to whom — and metadata is usually the part that matters, which is exactly why it is worth protecting.