IP Addressing and Subnetting for AV

Every device on an AV network—Dante endpoints, PTZ cameras, control processors, displays, video-over-IP encoders—requires a unique IP address. Getting your addressing scheme right at installation time prevents conflicts, simplifies troubleshooting, and makes future expansions painless.

IPv4 Address Basics

IPv4 addresses are 32-bit numbers expressed as four octets (e.g., 192.168.10.50). Each address has two parts: the network portion (identifying which subnet the device belongs to) and the host portion (identifying the specific device). The subnet mask defines where the split happens.

Common subnet masks:

For most AV installations, a /24 subnet (up to 254 devices) is sufficient per VLAN. Larger campus or broadcast facilities may need /23 or /22 blocks.

Private Address Ranges

Use private RFC 1918 address space for AV devices—they should never be directly reachable from the public internet:

• 10.0.0.0/8 — Large enterprise or campus networks
• 172.16.0.0/12 — Medium-sized deployments
• 192.168.0.0/16 — Smaller rooms and standalone systems

A common scheme for AV: reserve 10.10.x.0/24 for AV VLANs, with each room or zone on its own /24. For example, 10.10.1.0/24 for Room 101, 10.10.2.0/24 for Room 102. This makes IP addresses self-documenting and simplifies ACL design.

Address Assignment Strategy

AV devices typically fall into two categories for addressing:

Static IP — control processors, DSP engines, matrix switchers, PTZ cameras, and any device that other systems need to reliably find. Assign these from a reserved block at the top of the subnet (e.g., .200–.254) and document them in your as-built drawings.

DHCP — laptops, bring-your-own-device endpoints, and temporary connections. Reserve a DHCP pool in the middle of the subnet range and keep it separate from static assignments.

For Dante and AES67 audio networks, all devices should use static IPs. Dante can technically use DHCP link-local addressing (169.254.x.x), but this causes problems in routed environments and makes the network harder to manage. Always assign static IPs for production Dante infrastructure.

Subnetting AV VLANs

Separating AV traffic onto dedicated VLANs requires matching the IP subnet to the VLAN. Each VLAN is its own Layer 3 broadcast domain. The pattern is:

• VLAN 10 → 10.10.10.0/24 (AV control)
• VLAN 20 → 10.10.20.0/24 (Dante audio)
• VLAN 30 → 10.10.30.0/24 (video-over-IP)
• VLAN 40 → 10.10.40.0/24 (building automation / IoT)

Inter-VLAN routing is handled by the Layer 3 switch or router. For AV systems, you generally want AV control devices to be able to reach all AV VLANs, but you may want to isolate audio and video transport VLANs from general corporate traffic.

Gateway and DNS for AV VLANs

Every AV VLAN that needs to communicate with other VLANs or the internet requires a default gateway—the IP address of the Layer 3 switch interface for that VLAN. On a Cisco switch, this is the SVI (Switched Virtual Interface):

interface vlan 20
  ip address 10.10.20.1 255.255.255.0
  no shutdown

The gateway address (10.10.20.1) is what each AV device in VLAN 20 should have set as its default gateway.

DNS for AV devices: Most AV devices don't use DNS for their core functions (Dante uses mDNS/Bonjour, not DNS), but control processors that integrate with cloud services or APIs need DNS resolution. Configure your DNS server address on control processors and any cloud-connected devices. Common choices: internal DNS server, or a public resolver like 8.8.8.8 for systems that need internet access.

Devices that never need to communicate outside their local subnet (pure Dante endpoints on an isolated VLAN) don't require a gateway or DNS entry—but leaving the gateway field blank on a misconfigured device can cause hard-to-diagnose connectivity issues if that device ever needs to reach outside the subnet.

CIDR and Supernetting

CIDR (Classless Inter-Domain Routing) notation compactly expresses a network address and its mask. 192.168.10.0/24 means the first 24 bits are the network address, leaving 8 bits for hosts (256 addresses, 254 usable after reserving the network and broadcast addresses).

When planning a multi-room installation, allocate a supernet block for the entire project. If each room gets a /24, a 20-room facility needs 20 /24 subnets. Reserving a /19 block (10.10.0.0/19 = 8,192 addresses, covers 32 /24 subnets) at the start gives room to grow without re-addressing.

IPv6 Considerations on AV VLANs

Many modern AV devices include IPv6 support that is enabled by default, even if the network operator doesn't intend to use IPv6. Unmanaged IPv6 traffic on AV VLANs causes two problems:

1. Multicast Neighbor Discovery (MND) — IPv6 uses multicast for ARP-equivalent neighbor discovery. On a switch without MLD (Multicast Listener Discovery) snooping enabled, this traffic floods all ports—similar to the IGMP snooping problem with Dante multicast.
2. Router Advertisement (RA) floods — Rogue RA messages from misconfigured devices can cause IPv6 address autoconfiguration storms on the segment.

Best practice: On dedicated AV VLANs (Dante, AES67), either disable IPv6 on AV devices explicitly, or enable MLD snooping on the switch alongside IGMP snooping. For most AV installations, disabling IPv6 on the AV VLAN is simpler and eliminates an unneeded variable.

IPAM — IP Address Management

In systems with more than a few dozen devices, tracking static IP assignments in a spreadsheet becomes error-prone. Dedicated IPAM (IP Address Management) tools provide:

• Visual subnet maps showing used and available addresses
• Conflict detection before address assignment
• DNS/DHCP integration
• Audit trail of who assigned what and when

Common IPAM options:

For most AV integrators, a well-maintained spreadsheet template is sufficient for individual projects. For clients managing hundreds of AV rooms, recommending or integrating with their existing IPAM is part of good service.

Link-Local Address Troubleshooting

When a Dante or AES67 device shows a 169.254.x.x address in Dante Controller or device management:

1. DHCP failure — The device is configured for DHCP but no DHCP server responded. Check DHCP server availability, DHCP helper/relay configuration across VLANs, and whether the device's port is on the correct VLAN.
2. Device lost its static configuration — Factory reset, firmware update, or configuration corruption reverted the device to DHCP. Reconfigure the static IP.
3. On an isolated segment by design — Small Dante systems sometimes run on a completely isolated switch with no DHCP or routing. Link-local works in this case but prevents management from any other subnet.

Devices at 169.254.x.x are unreachable from any routed network. Dante Controller must be on the same Layer 2 segment (or that segment's VLAN) to see them. This is a common cause of "device shows in Dante Controller on-site but not remote."

Common Pitfalls

• IP conflicts from undocumented static assignments — When multiple installers touch a system over time, static IPs get reused. Maintain an IP address management spreadsheet (or use dedicated IPAM software) and update it with every device added.
• Forgetting to match subnet mask on every device — A device with the correct IP but wrong subnet mask (e.g., /24 instead of /23) will fail to communicate with devices outside what it calculates as its local network. Always verify mask, gateway, and IP are consistent.
• DHCP scope overlapping with static assignments — If your DHCP pool includes addresses you've manually assigned to static devices, conflicts are inevitable when DHCP leases those addresses to new clients. Keep static and dynamic ranges separated by design, not just convention.
• Using 169.254.x.x (APIPA) in production — Link-local addresses work only on the local segment and can't be routed. Dante devices that fall back to 169.254.x.x are unreachable from other subnets and from management workstations on different VLANs.
• Not planning for IPv6 — Many modern devices include IPv6 support. If your network doesn't manage IPv6, multicast neighbor discovery traffic can interfere with AV protocols. Either enable IPv6 properly or disable it on AV VLANs.
• Missing gateway configuration on control processors — A control processor with no default gateway is unreachable from other VLANs. IT staff connecting remotely from a corporate VLAN will be unable to reach it even though it responds to pings within its own subnet.