How to Create an IP Schedule for AV Systems
By WireFlow Team · Published 2026-07-11 · Updated 2026-07-11 · 10 min read
An IP schedule is the single document listing every networked device in an AV system with its IP address, subnet, VLAN, MAC, and switch port. To create one: pick a private address range that won't collide with house networks, carve each subnet into blocks by device class, decide static versus DHCP-reservation per class, assign every device an address on paper before you configure anything, then keep the document matching reality as the system changes. Done right, it's the plan, the load-in punch list, and the troubleshooting map in one file.
What is an IP schedule?
An IP schedule is to the network what a cable schedule is to the wiring: the authoritative list of every assignment, written down before anything gets configured and kept current afterward. One row per network interface, device, hostname, address, subnet, VLAN, MAC, switch port, notes. A device with two NICs gets two rows.
The document earns its keep three times. During prep it's the plan, addresses get allocated deliberately instead of invented at each device's front panel. During load-in it's the punch list, configure, check off, move on. During the show it's the troubleshooting map: when a processor stops answering or the duplicate-IP gremlin appears, the schedule turns "what could that even be?" into a thirty-second lookup.
Choose an address space that won't fight you
Private networks draw from the three RFC 1918 ranges: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Any of them works technically. The practical advice is blunter: stay out of 192.168.0.x and 192.168.1.x. Nearly every consumer router defaults there, which means venue networks, rental modems, presenter hotspots, and half the temporary gear you'll ever meet already live there. Address collisions and confused routing follow the defaults around.
A 10.x scheme with numbers that mean something to you (10.org.vlan.device is a common pattern) almost never collides with a house network and leaves room to encode structure:
- One /24 subnet per VLAN. 254 usable addresses is plenty for most shows, and the math stays out of your way.
- Third octet mirrors the VLAN ID. VLAN 20 lives in 10.10.20.0/24, so any address names its own network, the scheme pairs directly with your VLAN plan.
- Same scheme on every show. Muscle memory is documentation that never gets lost in a handover.
Reserve address blocks by device class
Inside each /24, reserve ranges so the address itself tells you what kind of device answers. You shouldn't need the schedule open to guess that .1 is the gateway and .10 is a processor. A carve that covers most systems:
| Last octet | Reserved for | Typical residents |
|---|---|---|
| .1–.9 | Network infrastructure | Gateway/router at .1, core switch at .2, edge switches, wireless APs |
| .10–.29 | Processors & system cores | Video switcher, audio console, DSP, LED processors, media servers |
| .30–.59 | Sources | Cameras, playback machines, graphics computers |
| .60–.79 | Destinations & control surfaces | Recorders, streaming encoders, touch panels, control processors |
| .100–.199 | DHCP pool | Guest laptops, temporary gear, anything transient |
| .200–.249 | Spares & staging | Loaner devices, bench-test addresses, next show's expansion |
Static, DHCP, or DHCP with reservations?
There are three ways to give a device its address, and a working system usually mixes all three:
- Static, set on the device. The address lives in the device itself, so it survives a dead DHCP server, a rebooted router, and a network rebuilt at 6 a.m. The cost: every change is a walk to the device. The standard choice for show-critical core, switchers, consoles, processors.
- DHCP with reservations. The DHCP server always hands the same MAC the same address. Central to manage, and the reservation table doubles as documentation, but a device only has its address while the server is alive and reachable. Common in fixed installs with real IT support.
- Plain DHCP pool. For everything transient, guest laptops, a lighting tech's tablet, gear visiting for a day. Undocumented individually by design; the schedule just records the pool's range.
Decision guidance: rigs that get rebuilt in a new room every week lean static for the core, because the network must come up in any order with no dependencies. Permanent installs with managed infrastructure lean reservations, because central management wins over years. Either way the schedule records the choice per device, the real failure mode isn't picking "wrong," it's nobody knowing what was picked.
The columns an IP schedule actually needs
Every column exists because its absence has a specific 2 a.m. failure attached:
| Column | Why it's there |
|---|---|
| Device | The human name, matching the diagram and gear list exactly, the key that joins the network docs to every other show document. |
| Hostname | What the device announces on the network. It's how the device shows up in discovery tools, web UIs, and logs. |
| IP address | The assignment itself, one row per interface on multi-NIC devices. |
| Subnet | Mask or CIDR. A wrong mask fails quietly: the device reaches its neighbors but never the gateway. |
| VLAN | Which logical network the interface lives on, this column pairs the schedule with the VLAN map. |
| MAC address | Required for DHCP reservations, and the only identifier that survives when labels fall off, it's how a mystery device on the switch gets matched to a row in this document. |
| Switch & port | Where the interface physically lands. Turns "can't reach it" into a specific port to walk to. |
| Notes | Where credentials are stored (never the credentials themselves), config quirks, "static set via front panel only" warnings. |
The full workflow, start to finish
The whole job, in order:
- List every networked device from the diagram and gear list. Anything with an RJ45, an SFP cage, or a Wi-Fi radio counts, including the utility gear nobody thinks of as networked.
- Group the devices into VLANs per your segmentation plan, one /24 per VLAN.
- Pick the address scheme, a 10.x plan with the VLAN ID as the third octet keeps every address self-describing.
- Carve each /24 into device-class blocks (infrastructure, processors, sources, control, DHCP pool, spares) and place every device inside its block.
- Decide static versus reservation per device class, and capture MAC addresses for everything that gets a reservation.
- Configure devices from the schedule, checking each row off as it's set, the schedule is the punch list.
- Verify: sweep the network with ping or a discovery tool, compare what answered against the schedule, and fix the document wherever reality won.
- Publish it with the rest of the show documentation, next to the diagram, not buried in an inbox.
Keep it as-built accurate
An IP schedule that drifted from reality is worse than none, it answers questions confidently and wrongly. The discipline is the same as for the as-built habit on signal-flow drawings: record the change at the moment it happens, device swapped, address reassigned, port moved, not from memory at the end of the day.
Give the document one owner per show or install. Everyone reads it; one person merges changes, on most crews that's whoever owns the network and the switch configs. Two people "fixing" the same schedule in parallel is how it stops being trusted, and an untrusted schedule is dead paper.
Build it from the diagram (and grab the free template)
The device that carries the IP address is the same device you already placed in the signal-flow drawing, so the least error-prone place to keep the assignment is on that device, not in a parallel spreadsheet. In WireFlow, IP addresses, VLANs, PoE, and switch-port documentation live on the diagram's devices; the IP schedule is derived from the drawing the same way the cable schedule and gear list are, and exports as CSV for the crew. Change the diagram and the schedule follows, because it's the same data.
Working spreadsheet-first instead? Download the free IP schedule CSV from the templates library, the same columns as the table above, no email gate. Pair it with the cable schedule method and you've documented the two systems crews most often have to rebuild blind.
Frequently asked questions
- What's the difference between an IP schedule and a DHCP reservation list?
- Scope. A reservation list only covers what the DHCP server hands out; an IP schedule covers every address in the system, static devices, reservations, pool ranges, and the plan behind them. The reservation list is one input to the schedule, not a substitute for it.
- Should every device get a static IP?
- No. Static addressing earns its cost on show-critical core gear that must come up with no dependencies. Transient devices belong in a DHCP pool, and documented-but-flexible gear suits reservations. The goal is that every address is deliberate, not that every address is static.
- What subnet size should an AV network use?
- A /24 per VLAN is the common answer: 254 usable addresses, easy math, and a broadcast domain that stays a reasonable size. If you're genuinely outgrowing a /24, that's usually a sign you want another VLAN for a distinct traffic class, not a bigger subnet.
- Where do I find a device's MAC address?
- Commonly on a factory label, in the device's network menu, or, once it's connected, in the switch's MAC address table for that port. Record it during commissioning while the device is in your hands; hunting MACs after installation is exactly the work the schedule exists to prevent.
Create your IP schedule in WireFlow
Assign addresses to devices on the diagram and export the IP schedule your crew loads in at the switch.