IP addressing and subnet planning
An address scheme the crew can read, that survives gear swaps, and that does not collide with the house or the next building.
What it is
IP planning is deciding, before anything is racked, what address each device gets, how it gets it, and how someone finds that out at half hour without calling you. That covers subnet sizing, which ranges belong to which department or rack, what is statically assigned versus reserved by DHCP, what the management addresses are, and how the scheme reads on a label. It also covers the legacy corners: Art-Net gear that ships defaulted into a 2.x or 10.x address, devices that self-assign a link-local address when they fail to find a server, and touring packages that arrive pre-addressed into a range the house is already using. The scheme is a document, not a convention held in one person's head.
Why it matters
Address problems present as protocol problems. A node that appears to ignore its universe is often a node on the wrong subnet. A tracking consumer that receives nothing is often a consumer whose route to the sender does not exist. These are quick to fix once identified and slow to identify under pressure, which is exactly the wrong shape of problem for a running show. A readable plan also makes a swap survivable: if a dead node can be replaced by setting one address from a printed table, the fix takes minutes and does not require the person who built the system. Over a long run, the crew who inherits the rig is the real audience for the addressing scheme.
Static addressing for anything that must return on its own; reservations only where the server is as reliable
Contiguous blocks per rack or role, so an added device gets an address without reverse-engineering the scheme
Art-Net gear defaulting to 2.x or 10.x needs a decision: readdress it, or carry that range deliberately
Check the house, production office and touring ranges for overlap before the two networks are ever patched together
Static or DHCP?
Static for control and tracking endpoints that have to come back after a power event without waiting on anything. DHCP with reservations is reasonable for larger populations of similar devices, such as access points or panels, provided the server is as available as the devices it serves. The failure to plan for is a DHCP server that is powered from a different source than the gear depending on it.
How large should subnets be?
Large enough that adding a rack does not force a renumber, small enough that broadcast and discovery traffic stays contained. Sizing follows the segmentation decision more than the device count. A common approach is one subnet per traffic class per production area, sized generously since address space is free and renumbering mid-run is not.
Do we renumber touring gear into the house scheme?
It depends on how often that package moves and who supports it. Renumbering gives one coherent scheme and one document, at the cost of changing a system the touring crew knows. Keeping the touring range and routing or bridging between schemes preserves their muscle memory but adds a translation point. Whichever way it goes, decide it before load-in and write it down, because the worst outcome is two half-applied schemes.