Static IP vs DHCP for AV Systems
By VJ Ries · Published 2026-07-12 · Updated 2026-08-01 · 10 min read
Static IP for show-critical core gear that must always answer at a known address (switchers, matrix frames, DSPs, LED and control processors). Use a DHCP reservation for managed devices that roam or get re-racked (cameras, touch panels, audio endpoints): a fixed address without hand-configuring each unit. Leave transient and guest clients (laptops, phones, tablets) on the plain DHCP pool. A device that comes up on a 169.254.x.x address found no DHCP server and self-assigned. Chase that as a symptom rather than an addressing plan.
What is the difference between static IP and DHCP?
Configured on the device itself, a static IP never changes. The device owns it and answers at that address whether or not anything else on the network is alive.
A DHCP address is handed out by a server from a pool, on a lease. The device asks for an address at boot and gets one for a while. It may get a different one later, when the lease expires or it moves to another network.
Most people skip the option that solves the most AV problems: the DHCP reservation, also called a static lease.
Matched by its MAC address, one specific device always gets the same address from the DHCP server. You get a fixed address, managed centrally at the server instead of typed into every box. That makes three approaches rather than two:
- Static IP: address lives on the device. Survives a dead DHCP server. You configure and track every one by hand.
- DHCP reservation: address lives on the server, pinned to a MAC. Fixed and central, but the device must reach the DHCP server to get it.
- DHCP pool: address assigned from a range on demand. Zero configuration, but the device can land on a different address next time.
Which addressing method should each device use?
You do not pick one method for the whole network.
You pick per device. One question decides it: does anything else on the network need to find this device at a predictable address? Walk each device through the tree:
- Is it show-critical, and do other devices reach it by IP (control strings, Dante subscriptions, stream pulls, NDI sources)? Give it a static IP. A changed address here silently breaks a control command or a subscription mid-show.
- Is it managed and semi-permanent, but might be swapped, re-racked, or moved between shows (cameras, touch panels, audio endpoints, PTZ heads)? Give it a DHCP reservation. Fixed address, but you never touch the device to set it.
- Is it transient, unmanaged, or a guest, and does nothing address it by IP (laptops, phones, tablets, a visiting presenter)? Leave it on the DHCP pool.
When to use a static IP
Static wins whenever the address is a dependency.
Control processors store the target IPs of the devices they drive: a matrix switcher, a display, a DSP. If that target moves, the control system keeps firing commands into the void while the symptom, a dead button on the touch panel, points nowhere near the cause. Anything other gear addresses by number should not be allowed to change its number.
- Core routing and processing: matrix frames, video switchers, LED processors, scalers, DSP cores.
- Control processors and their fixed targets, where the IP is written into a program or a preset.
- The infrastructure itself: managed switches, the gateway and anything you type into a browser to configure the rig.
When to use a DHCP reservation
A reservation gives you a fixed, documented address without configuring the device by hand.
The device stays set to DHCP and the server just always answers it with the same address, which is exactly right for the large middle tier of an AV rig: gear that is managed and needs a knowable address, but circulates enough that hand-setting statics on every unit is a maintenance tax you will eventually forget to pay.
It also centralizes the record.
Every reservation lives in one place, the DHCP server, so the address plan and the reservations are one list. That is the discipline behind a good IP schedule: one source of truth, rather than addresses scattered across forty device menus.
When to leave a device on the DHCP pool
If nothing addresses a device by IP, it does not need a predictable address. Pinning one is just work with no payoff. Laptops, phones, tablets, a presenter's machine. Let the pool handle them. They initiate their own connections outward (to a stream target, the internet, a control web page), so they never need to be found at a known number.
One rule governs the pool. Fence it off from your static and reservation ranges so DHCP can never lease an address you already nailed to a processor, an overlap covered in preventing duplicate IP addresses.
Which method by gear type?
Treat the table below as a starting default, not a manufacturer requirement. Real defaults vary by brand and firmware. Some ecosystems have strong opinions about addressing. Confirm against the device datasheet and whoever owns the network before you commit the plan.
| Gear type | Typical method | Why |
|---|---|---|
| Matrix, switcher, DSP core, LED and control processors | Static IP | Show-critical and addressed by other gear; must answer at a fixed, known address. |
| Managed switches, gateway, infrastructure | Static IP | You configure them by address; they must be reachable before DHCP exists. |
| Cameras, PTZ heads, encoders | DHCP reservation | Managed and knowable, but circulate between shows; central record beats hand-setting each. |
| Touch panels and control UIs | DHCP reservation | Need a predictable address for the control system, but are easy to re-provision centrally. |
| Networked audio endpoints (Dante, AVB) | Static IP or reservation | Depends on the ecosystem and controller; commonly ship on DHCP, so verify the vendor default. |
| Laptops, phones, tablets, guest devices | DHCP pool | Transient and unaddressed by other gear; a fixed address buys nothing. |
How do you carve one subnet into static, reservation, and pool?
Three ranges live happily on one subnet, as long as they never overlap. Static. Reservation. Pool. The clean way is to split the address space into blocks up front and write the split into your schedule, so no one hand-assigns an address that DHCP will later try to lease. A worked example on a /24:
Subnet: 10.0.10.0/24, usable .1 to .254 .1: gateway .2 to .49: static core gear (switchers, DSP, processors, infrastructure) .50 to .99: DHCP reservations (cameras, panels, audio endpoints) .100 to .199: DHCP pool (transient and guest clients) .200 to .254: spare, held for growth
Illustrative split only. Size each block to your real device counts, and confirm the subnet mask and gateway with whoever owns the network before you assign anything.
Whatever numbers you choose, the DHCP pool and the static block cannot touch. Set the DHCP scope to hand out only the pool range. Keep the static and reservation blocks outside it. Record all three in the same document.
How to document static vs DHCP on your diagram
An addressing plan that lives in one tech's head is a single point of failure with a pulse.
Record the method for every managed device (static, reservation or pool) along with the address, on the same drawing as the signal flow, so the person who did not build the rig can still find the encoder that dropped. In WireFlow, the diagram itself holds IP assignments, VLANs and switch ports. It exports them as the IP schedule your crew loads in at the switch.
- Tag every managed device with its method and address, and note the MAC beside any reservation so a spare can be re-pinned fast.
- Keep the static block, the reservation block and the pool visible as ranges, rather than as scattered per-device numbers.
- Tie the addressing plan back into the preproduction workflow and your port-to-port documentation, so the address, the switch port and the cable ID all point at the same device.
Frequently asked questions
- Is a DHCP reservation the same as a static IP?
- No, though the result looks similar: both give a device a fixed address. The difference is where the address lives. A static IP is configured on the device itself and works even if the DHCP server is down. A reservation lives on the DHCP server, keyed to the device's MAC address. The device stays set to DHCP. Reservations are easier to manage centrally; statics are more resilient when the network is half-built.
- Should Dante or networked-audio devices use static or DHCP?
- It depends on the ecosystem and the controller. Treat this as a check-the-vendor question rather than a fixed rule. Networked-audio devices commonly ship set to DHCP with a link-local fallback, and many shops run them on DHCP or reservations. Confirm the manufacturer default and your audio controller's expectations. Above all, keep the method consistent across the audio network.
- Why did my device come up on a 169.254 address?
- Because it is set to DHCP but no DHCP server answered. So it self-assigned a link-local address from the 169.254.0.0/16 range, sometimes called APIPA. Two devices on 169.254 can occasionally talk to each other but not to the rest of the network. On a show it means the DHCP server is down or missing; the device is on the wrong VLAN or port; or the cabling is wrong. It is a symptom, not a valid plan.
- Can static and DHCP coexist on the same network?
- Yes. On almost every AV network they do. The requirement is that the DHCP pool and the static and reservation blocks never overlap. Set the DHCP scope to hand out only the pool range. Keep your static addresses outside it.
- What happens if two devices claim the same IP?
- You get an address conflict. One or both devices drop off intermittently as the network's ARP mapping flips between them. The classic tell is a device that works fine until another one powers up. Prevent it by carving non-overlapping ranges and keeping a single address plan, covered in preventing duplicate IP addresses.
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.