How to Prevent Duplicate IP Addresses in AV Systems

Why AV rigs are duplicate-IP factories

Office networks rarely see IP conflicts anymore, everything leases from DHCP and nothing moves. Show networks are the opposite case: gear arrives from three rental houses on load-in morning, half of it carries addresses someone set for the last gig, and the network is supposed to be up by lunch. The conflict isn't bad luck; it's the default outcome of how AV gear circulates.

• Rental gear ships with history. A processor or encoder comes back from every show wearing whatever static IP the last tech gave it. Nobody factory-resets between rentals.
• Factory defaults collide by design. Many devices ship with common defaults in familiar private ranges, low addresses in 192.168.0.x or 192.168.1.x are typical patterns, so two fresh-from-the-box units of different brands can claim the same address before anyone touches them.
• DHCP and statics share a subnet. A DHCP server that doesn't know about your static block will eventually lease an address you already nailed to a camera.
• Two techs, one subnet, no schedule. Parallel config sessions during load-in each grab the next "obviously free" address, the same one, twice.

What an IP conflict looks like on a show network

A duplicate IP rarely announces itself. Two devices claim one address, and the network's ARP mapping, the table that ties an IP to a physical MAC address, flips to whichever device answered most recently. Traffic follows the flip. What the crew actually sees:

• Intermittent dropouts. A camera feed or control connection works, dies for thirty seconds, and returns untouched.
• Devices fighting. The control system reaches its touch panel until the encoder wearing the same address answers first. Both look flaky; neither is broken.
• Works-when-the-other-is-off. The classic tell: device A behaves perfectly until device B powers up.
• ARP weirdness. The switch shows one IP flapping between two MAC addresses, and any laptop on the subnet may throw an "address conflict" warning.

The cruelty is that the failure is timing-dependent. It moves. So it gets blamed on cable, firmware, Wi-Fi, the venue, anything but what it is.

Prevention: one schedule, reserved ranges, bench config

Duplicates are prevented on paper, not on the network. Every practice below is a way of making sure an address exists in exactly one place, the plan, before it exists on a device.

• One IP schedule, one owner. Every address on the rig lives in the IP schedule before it lives on a device, and one person owns the document. Two half-maintained spreadsheets are worse than none, here's how to build an IP schedule that crews actually keep current.
• Carve ranges so they can't overlap. Statics in one block, the DHCP pool in a separate block, per network, for example statics in .10–.99 and the pool in .100–.199. The exact split is taste; the non-overlap is the rule. Do it per VLAN if you segment, see VLAN planning for AV systems.
• DHCP reservations for roaming gear. Laptops, wireless tablets, and anything that moves between networks gets a reservation tied to its MAC address: it always receives the same address, but the server hands it out, so it can never be claimed twice.
• Configure at the bench, not the dock door. Set each device to its scheduled address during prep, verify it answers, and only then case it. Load-in is the worst possible place to discover two units fighting.
• Label the gear with its IP. Tape or a printed label on the device itself. The tech at the switch shouldn't need a login to know what the box in front of them claims to be.

Detection: finding the duplicate when it happens anyway

Mid-show, with symptoms live, work the tree below. The commands are concept-level, exact CLI syntax varies by switch vendor and OS, but every managed switch exposes these tables.

1. Prove it's a conflict, not a dead device. Ping the suspect address continuously from a laptop on the same network. Replies that come and go in bursts, or response behavior that changes when specific gear powers on, point at two claimants.
2. Unplug-and-ping isolation. Unplug or power down the device you *believe* owns the address. If the address still answers, something else owns it too. That's your proof, and it took thirty seconds.
3. Read the ARP table. On the switch or a laptop, list the ARP entries (conceptually "show arp" on most switch CLIs, "arp -a" on a laptop; syntax varies). Note which MAC address is currently answering for the IP.
4. Identify the vendor from the MAC. The first half of a MAC address is the manufacturer's OUI prefix. Looking it up often shrinks the suspect list from "anything on the rig" to "one of the encoders."
5. Hunt the physical port. Search the switch's MAC address table for that MAC (conceptually "show mac address-table"). It returns the port where the MAC lives; follow the patch to the device. If it points at an uplink, repeat on the next switch down.
6. Fix per the schedule, not ad hoc. Give the offender its scheduled address, update the schedule if reality has drifted, and re-verify both devices. An ad-hoc "any free address" fix is how the next conflict gets planted.

Catch it at plan time, not show time

The cheapest duplicate to fix is the one that never leaves the drawing. In WireFlow, IP assignments live on the same diagram as the signal flow, each networked device carries its address, VLAN, and switch port in one view, documented port to port, so two devices wearing the same address are a visible paperwork problem during planning instead of a moving target during the show. The exported IP schedule becomes the bench checklist, which is most of what reducing setup mistakes comes down to.

The same network layer carries the PoE budget, so the switch plan, addresses, VLANs, power, stays one document with one owner instead of three spreadsheets with none.

Frequently asked questions

How do I find which device is causing an IP conflict?

Prove the conflict first: unplug the device you think owns the address and keep pinging, if it still answers, there's a second claimant. Then read the ARP table to get the answering MAC address, look up its vendor prefix to narrow the suspect list, and search the switch's MAC address table to find the physical port it lives on.

Can two devices have the same IP on different VLANs?

Technically yes, VLANs are separate broadcast domains, so the addresses never meet. In practice most crews keep addressing unique across the whole rig anyway: it costs nothing, it removes a whole class of human error, and it keeps your options open if two networks ever need to be bridged or merged mid-tour.

Should show gear use DHCP or static IPs?

Both, deliberately. Infrastructure and anything another device points at, switches, processors, cameras, control processors, gets statics from the schedule. Guest laptops and roaming gear get the DHCP pool, carved so it can't overlap the static block, with reservations for crew devices that should keep a stable address.

Why does a device work alone but fail on the full rig?

That's the signature of a duplicate address. On the bench, the device is the only claimant, so everything resolves to it and it behaves perfectly. On the rig, the second claimant answers some of the time and traffic splits between them. Any fault that appears only when a specific other device powers up deserves an immediate ARP check.

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.

Start a free IP plan · Download the IP schedule template