Dante IP Addressing: DHCP, Link-Local, and Static IPs
8 min read · Updated October 2, 2026 · system technicians, AV network engineers, FOH and monitor engineers, broadcast operators, production managers, venue technicians, and touring audio teams
Choose and troubleshoot Dante IP addressing with DHCP, link-local, or static addresses, including subnet checks, recovery, and rider documentation.
TL;DR — Dante devices normally obtain an address automatically: from DHCP when a server is present, or from the link-local range when it is not. A 169.254.x.x primary address is therefore not automatically an error. Keep every device and the control computer on the intended network and subnet, avoid accidental duplicate or mixed schemes, and use static addressing only when the approved network design requires it. Record the addressing owner and recovery path before show day.
Dante can configure its own address
An IP address identifies a device interface on an IP network. Dante uses IP networking for discovery, control, clocking, and media transport, but a small Dante system does not require an operator to type an address into every endpoint.
By default, a Dante device generally follows one of two automatic paths:
| Network condition | Typical result | Operational meaning |
|---|---|---|
| A reachable DHCP server is present | The server leases an address from its configured subnet | Address policy is owned by the DHCP/network administrator |
| No DHCP server is present | The device self-assigns a link-local address, commonly 169.254.x.x on the primary network | A standalone same-link network can operate without a router |
| A device was manually configured | It keeps the static address and netmask until changed | The operator must preserve a correct, unique, documented scheme |
Automatic does not mean arbitrary. The devices and Dante Controller computer still need compatible addresses on the intended interface. An address can be valid by itself and still be wrong for the network where it was connected.
DHCP, link-local, and static solve different problems
Use DHCP when the network team owns addressing
DHCP is useful on installed or shared infrastructure because one service can allocate unique addresses, netmasks, and related settings under a managed policy. It also reduces manual entry errors.
Before relying on it, confirm:
- the DHCP service reaches the correct Dante VLAN or subnet;
- primary and secondary redundant networks do not receive overlapping schemes;
- lease capacity covers every endpoint and control computer;
- reservations, if used, match the network team's records;
- loss or restart of the service has a tested operational outcome.
Do not add an improvised DHCP server to a venue network. Two uncoordinated servers can assign conflicting or unintended configurations.
Use link-local for a simple standalone network
When no DHCP server answers, Dante hardware can use link-local addressing. Primary interfaces commonly appear as 169.254.x.x. A control computer set to obtain an address automatically can join the same scheme.
Link-local is a practical fit for a small, single-subnet, temporary audio network. It does not provide a gateway to other IP networks, and it does not make multicast discovery cross a router. If a laptop keeps a corporate Wi-Fi or wired interface active at the same time, verify which adapter Dante Controller selected.
Use static addresses only for a defined design
Static addressing may be appropriate when an enterprise policy, routed design, management system, or support procedure needs predictable addresses. It also adds operational obligations:
- Allocate a unique address before configuration.
- Confirm the subnet mask and any gateway requirement.
- Keep primary and secondary networks separate.
- Record the address against the physical device and port.
- Plan how a replacement endpoint receives the correct configuration.
- Test how to regain access after an incorrect entry.
Changing an endpoint to a static address may reboot it. Treat the change as maintenance, not as an experiment during a performance.
Read the address pattern before changing anything
When devices disappear from Dante Controller, first inventory what exists. Do not immediately force every endpoint to a memorized static subnet.
| Observation | Likely question to investigate |
|---|---|
| Most devices are 169.254.x.x; one is private 10.x.x.x | Is one endpoint still static or receiving DHCP from another network? |
| Devices use a venue subnet; laptop is 169.254.x.x | Can the laptop reach the venue DHCP service, and is the correct adapter selected? |
| Primary and secondary interfaces share one subnet | Are the supposedly redundant networks accidentally bridged or served by overlapping DHCP scopes? |
| One address duplicates another | Which device or reservation owns it, and can both be isolated before correction? |
| Device appears after a direct connection but not through the system | Which switch, VLAN, cable, or routed discovery boundary differs? |
The visible symptom may be addressing, interface selection, cabling, VLAN membership, or discovery scope. Separate those layers before editing the configuration.
Troubleshoot missing devices in a fixed order
1. Protect the known-good show state
Save the current Dante configuration where supported. Record device names, subscriptions, clock state, sample rate, port mode, addresses, and the physical patch. Avoid changing multiple layers at once.
2. Confirm the physical interface
Check link indicators, cable path, switch port, negotiated speed, and whether the endpoint uses its primary, secondary, or switched port. A cable in the wrong redundant port can look like an IP problem.
3. Inspect every address and mask
Use Dante Controller's device information and the operating system's network settings. Compare the scheme on all primary interfaces separately from all secondary interfaces. Look for duplicates, unexpected static entries, and inconsistent masks.
4. Select the intended computer adapter
A laptop may have Ethernet, Wi-Fi, VPN, virtual-machine, and USB network adapters. Select the adapter physically connected to Dante. Avoid multiple active interfaces in the same subnet because the operating system may choose an unintended path.
5. Restore one consistent policy
If the approved design is automatic, return the affected endpoint and computer to automatic addressing and allow time for configuration. If it is static, use the documented allocation rather than inventing a free-looking address.
6. Verify discovery and media separately
Seeing a name in Controller proves discovery, not a complete audio path. Confirm clock status, sample rate, subscriptions, receiver errors, and actual audio. The Dante sample-rate mismatch guide covers a common case where endpoints are visible but audio cannot subscribe.
Keep redundant networks truly separate
On devices configured for Dante redundancy, primary and secondary ports belong to separate network paths. Do not connect them to the same flat network, bridge their switches, or give them overlapping address scopes.
The secondary link-local scheme may differ from the primary scheme. A control computer connected to the secondary network can require a compatible manually configured address, depending on the interface and current Dante guidance. Follow the supported procedure for the deployed version rather than copying primary settings.
For port modes and failure domains, use the Dante redundant versus switched mode guide.
Document an address plan someone else can recover
A useful network handoff should name:
- the primary and secondary network or VLAN;
- DHCP, link-local, or static policy for each;
- DHCP owner and reservation source, when applicable;
- permitted subnets and masks;
- device names, physical ports, and current addresses;
- Dante Controller computer and adapter;
- switches, uplinks, and any routing boundary;
- who may change addressing;
- baseline file, test procedure, and recovery contact.
Do not put passwords or sensitive network credentials in a public technical rider. Share access details through the venue's approved secure channel.
The broader digital audio network tech rider guide shows how addressing fits beside routing, clock, redundancy, and ownership.
Dante IP addressing checklist
- The control computer uses the intended wired adapter.
- Every primary interface follows one compatible address scheme.
- Every secondary interface follows its own separate scheme.
- No duplicate static address or overlapping DHCP scope is present.
- DHCP ownership and capacity are confirmed where used.
- Static addresses have an approved allocation and recovery record.
- Device discovery, clock, subscription, and real audio are tested.
- The baseline and responsible network owner are documented.
Common mistakes
Treating 169.254 as a failure. On a standalone network without DHCP, a link-local address can be the correct automatic result.
Changing all devices to static addresses. This can replace one clear fault with duplicates, wrong masks, and undocumented dependencies.
Leaving several computer adapters in the same subnet. Controller or the operating system may use the wrong interface.
Combining redundant networks. Shared switches, bridges, or address scopes remove the isolation that redundancy is meant to provide.
Stopping when devices appear. Discovery is only one check; verify clocking, subscriptions, latency, and audio.
FAQ
Does Dante need a DHCP server?
No. Dante devices can self-assign link-local addresses on a standalone network without DHCP. DHCP is useful when an installed or managed network needs centrally controlled addressing.
Why does my Dante device have a 169.254 address?
It usually means the primary interface did not receive a DHCP lease and selected a link-local address. That is normal when the other Dante devices and control computer are on the same link-local network.
Should Dante devices use static IP addresses?
Usually not by default. Use static addresses only when the approved system design requires predictable addressing, and document unique allocations, masks, owners, and recovery.
Why is a Dante device not showing in Dante Controller?
Check physical link, port mode, the selected computer adapter, IP address and mask, duplicate addresses, VLAN membership, and discovery boundaries. Correct one layer at a time.
How do you recover a Dante device with the wrong IP address?
Connect through a compatible local network path, identify the device and current scheme, then restore automatic addressing or the documented static allocation using the supported controller procedure. Avoid guessing addresses on the production network.
Build the network handoff into the Rider
Record the verified addressing policy beside device names, routes, clock, switch paths, and recovery ownership. In Techrider.live, keep that handoff with the same Rider as the stage plot and input list, invite the responsible engineer to edit it, then save and inspect history before sharing the current version.
Related guides
What Is a Stage Plot? (And How to Read One)
A stage plot is a top-down map of your band's stage setup. Learn what goes on it, how it differs from an input list and tech rider, and what makes one engineer-readable.
6 min readBasicsWhat Is a Tech Rider? (Sections Explained)
A tech rider is the full technical package a band sends a venue — console, monitors, PA, backline, power, stage plot, input list, hospitality. Learn every section.
7 min readBasicsStage Plot Symbols & Legend Explained
A visual glossary of stage plot symbols — mics, DI boxes, wedges, IEM packs, drums, amps, keys, power drops. Learn what each icon means and how to read any stage plot.
7 min read