IT for AV/Lesson 24

System design 11 min read

Designing an AVoIP Network from Requirements to Commissioning

Turn endpoints and traffic requirements into topology, bandwidth budgets, switch schedules and commissioning evidence.

Why an AV engineer should care

This is where the previous lessons become a real project.

A manufacturer may provide a switch configuration guide, but it does not know:

  • How many sources the project has
  • Which receivers can select which sources
  • Where traffic crosses uplinks
  • What happens during a link failure
  • Which systems share the network
  • Who owns routing, DHCP, gateways and security
  • Whether the client expects five years of expansion

AVoIP network design begins with the system’s required behavior. VLAN numbers and switch models come later.

Learning objectives

By the end of this lesson, you should be able to:

  • Build an endpoint and stream inventory.
  • Calculate normal and failure-path bandwidth.
  • Define VLAN, multicast, timing and gateway responsibilities.
  • Select switches from technical requirements.
  • Produce drawings and commissioning records that another engineer can actually use.

1. Start with the endpoint inventory

Before drawing the network, create one row for every networked endpoint.

At minimum, record:

  • Device and role
  • Physical location
  • Network-interface speed
  • PoE requirement
  • Media format and maximum bitrate
  • Unicast or multicast behavior
  • Number of simultaneous transmitted and received streams
  • VLAN requirements
  • PTP requirement and domain
  • Management method
  • Static IP, DHCP or link-local behavior
  • Redundant-interface or switched-port mode
  • USB or auxiliary Ethernet behavior

A Visionary Solutions Duet encoder, for example, cannot be described merely as “one encoder with one network cable.” Depending on its configuration, that connection may carry tagged PacketAV video, Dante/AES67 audio and traffic for the expansion Ethernet port.

Likewise, a computer running NDI may contain:

  • One or more NDI transmitters
  • Several NDI receivers
  • A control application
  • A discovery client
  • A management interface
  • A completely unrelated office-data workload

The box count does not reveal the traffic.


2. Build a traffic matrix

For each media source, record:

  • Maximum bitrate
  • Possible destinations
  • Maximum simultaneous destinations
  • Transport type
  • Path through the topology
  • Required behavior after a failure

A useful planning formula is:

Link load =
Σ(distinct multicast streams)
+
Σ(unicast stream copies)
+
other traffic

Multicast calculation

If twelve decoders on one access switch watch the same 800 Mb/s multicast source, the uplink normally carries one 800 Mb/s copy. The access switch replicates it to twelve receiver ports.

If those decoders collectively watch six different 800 Mb/s sources, the uplink carries approximately:

6 × 800 = 4,800 Mb/s

The deciding value is the number of distinct groups crossing the link.

Unicast calculation

If one 130 Mb/s NDI source supplies three receivers using unicast, the source-facing path may carry:

130 × 3 = 390 Mb/s

NDI’s guidance emphasizes aggregate bandwidth across simultaneous channels and checking the switch’s actual throughput, not only its port labels. NDI bandwidth guidance.

Failure-path calculation

Repeat the calculation after:

  • An uplink failure
  • A stack-member failure
  • A ring opening
  • A LAG member failure
  • Loss of one redundant fabric
  • Maximum credible source selection

A system is not redundant merely because packets can still find a path. The remaining path must have enough capacity.

Calculate both:

  • Normal operating load
  • Worst credible failure load

Choose and document headroom for the project instead of assuming one fixed percentage fits every system. A highly predictable dedicated network may accept one target; a converged client network may need considerably more margin.


3. Turn traffic into topology

Now decide where switching occurs.

A common design has:

  • Endpoint connections at access switches
  • High-speed fiber uplinks
  • A core, stack or pair of aggregation switches
  • A router or firewall providing controlled inter-VLAN access
  • Separate management access
  • Optional redundant network paths

For every link, show:

  • Port speed
  • Copper or fiber medium
  • Optic type
  • Native and tagged VLANs
  • LAG membership
  • Expected normal load
  • Expected failure load

Remember the LAG limitation

Two 10 Gb/s links may provide 20 Gb/s of aggregate capacity, but a single flow is normally hashed onto one physical member.

A 12 Gb/s flow cannot generally divide itself into two 6 Gb/s pieces. LAGs distribute separate conversations, and the distribution may be uneven.

For high-bandwidth multicast, confirm how the selected switch hashes multicast traffic. Do not assume four links will always produce four perfectly balanced buckets of happiness.


4. Select switches from the requirements

A switch qualifies only if its complete configuration meets the design.

Check:

Physical interfaces

  • Required 1, 2.5, 10, 25, 40 or 100 Gb/s ports
  • Correct SFP/SFP+/SFP28 modules
  • Fiber type and distance
  • Port breakout requirements
  • Supported transceiver combinations

PoE

  • PoE standard and class per endpoint
  • Required power at the powered device
  • Switch’s total PoE budget
  • Available budget with redundant power supplies
  • Power behavior after one supply or stack member fails

Performance

  • Switching capacity
  • Forwarding rate
  • Uplink capacity
  • Multicast-group and MAC-table limits
  • Buffer architecture
  • Maximum VLANs and LAGs
  • Stack or chassis bandwidth

Network features

  • IGMP snooping version
  • IGMP querier capability
  • PIM when multicast must be routed
  • QoS classification and queue control
  • ACL capability
  • DHCP snooping and port security where appropriate
  • PTP boundary- or transparent-clock support when required
  • SNMP, syslog and configuration backup
  • Licensing needed to enable those features

An operable ST 2110 design illustrates the broader principle: media transport alone is insufficient. Timing, discovery, connection management, configuration, monitoring and security all belong in an operable system.

This same principle applies to commercial AVoIP. A switch that forwards the packets today may still be a poor choice if nobody can monitor or recover it tomorrow.


5. Design the VLAN and Layer 3 boundary

Create a VLAN/IP schedule before configuring ports.

For each VLAN, identify:

  • VLAN ID and name
  • Subnet and mask
  • Default gateway
  • Device providing the gateway
  • DHCP server or static-address plan
  • DNS and NTP access
  • IGMP querier
  • PTP domain or timing service
  • Permitted inter-VLAN communication
  • Management access
  • Responsible party

A switch can have a management virtual interface without routing every AV VLAN. If the client’s firewall or core router should provide Layer 3 services, do not assign competing gateway SVIs to the AV switches.

One VLAN should have one intentional default-gateway address. Two devices advertising themselves as the gateway is not redundancy unless a coordinated first-hop redundancy protocol was deliberately designed.

Separate for a reason

Possible logical networks include:

  • AVoIP video
  • Dante audio
  • Control
  • Device management
  • Client LAN
  • Wireless presentation
  • Expansion or pass-through ports

These do not always need separate VLANs. Separate them when required by:

  • Security boundaries
  • Multicast containment
  • Manufacturer requirements
  • Timing behavior
  • Administrative ownership
  • Fault isolation
  • Bandwidth policy

Avoid creating fifteen VLANs merely because fifteen traffic descriptions exist. Complexity must purchase something useful.


6. Define multicast completely

For every multicast VLAN, document:

  • IGMP version
  • Snooping configuration
  • Querier address and location
  • Multicast address range
  • Routed or Layer 2-only operation
  • PIM requirements, if routed
  • Fast-leave policy
  • Links that must carry multicast
  • Validation method

Without effective querying and snooping, multicast video may flood ports that never requested it. NDI’s official guidance describes the same risk and the role of IGMP snooping. NDI multicast guidance.

Dante audio does not universally require IGMP because ordinary subscriptions are commonly unicast. Multicast Dante and Dante AV change the calculation. Audinate’s guidance distinguishes audio-only networks with little multicast from multicast-video networks that require snooping. Dante IGMP guidance.

The right configuration depends on the traffic, not the presence of the word “Dante.”


7. Produce an engineering package

A defensible network package should include:

Network basis of design

A short narrative explaining:

  • System purpose
  • Media technologies
  • Design assumptions
  • Ownership boundaries
  • Redundancy objectives
  • Capacity and expansion targets

Physical riser

Show:

  • Switches and stacks
  • Endpoint quantities
  • Fiber and copper links
  • Uplink speeds
  • Redundant paths
  • Rack and room locations

Logical network diagram

Show:

  • VLANs and subnets
  • Gateways and routing
  • DHCP, DNS and NTP
  • Querier locations
  • PTP leaders
  • Controllers, registries and management servers

Schedules

Include:

  • Endpoint and stream schedule
  • Switch-port schedule
  • VLAN/IP schedule
  • Multicast schedule
  • PoE budget
  • Normal and failure-path bandwidth
  • Optics and module schedule
  • Configuration-responsibility matrix

The responsibility matrix matters. “By IT” is not a configuration.

Record whether the consultant, integrator, client IT or a manufacturer is responsible for each VLAN, ACL, DHCP scope, querier, QoS policy, certificate, user account and configuration backup.


8. Commission the design, not just the devices

Commissioning should verify:

  • Every link negotiates at the intended speed
  • VLAN tagging matches the port schedule
  • DHCP and static addressing behave correctly
  • Gateways and ACLs permit only required communication
  • Multicast groups join and leave properly
  • The querier remains active
  • PTP selects the intended leader
  • QoS markings reach the expected queues
  • Interface errors and discards remain clean
  • SFP DOM readings are within budget
  • Maximum planned routes operate simultaneously
  • Failure paths carry the load
  • Redundant media actually survives a disconnected link
  • SNMP and syslog report meaningful faults
  • Configuration exports can be restored

Leave monitoring running long enough to expose intermittent problems. Collect latency and error history after network changes and increased endpoint load, rather than accepting one clean snapshot.

Save the final evidence:

  • Switch configurations
  • Endpoint configurations
  • Firmware versions
  • Controller exports
  • Screenshots or reports
  • Test results
  • Known limitations
  • Recovery procedures

Commercial-AV example: centralized encoders

Eight 750 Mb/s multicast encoders connect to the core. Two access switches serve decoders through 10 Gb/s uplinks.

If every access switch may need all eight sources:

8 × 750 = 6 Gb/s

Each uplink must carry at least 6 Gb/s plus overhead and other services.

If the uplink is a two-member 10 Gb/s LAG, test the actual multicast distribution. If one member fails, the remaining 10 Gb/s link must carry the entire planned load.

If a proposed backup path is only 1 Gb/s, it cannot provide functional redundancy for all eight streams.

Commercial-AV example: tag-aware Duet endpoint

A Duet encoder uses:

  • VLAN 110 for PacketAV video
  • VLAN 120 for Dante/AES67
  • VLAN 130 for its expansion Ethernet port

The switch port must carry all three as matching tagged VLANs. The drawing should also show what network the expansion port exposes.

In the described tag-disabled configuration, traffic shares the switch port’s untagged VLAN; verify the exact endpoint model, firmware and expansion-port configuration. That could place Dante on the video network and allow someone using the expansion port to join that same network.

The endpoint schedule therefore needs the VLAN behavior, not just an IP address. Verify the exact Duet model against its manual; this example uses the Duet-2 VLAN-capable architecture.

Practical exercise

A project has:

  • Six 800 Mb/s multicast encoders at the core
  • Two access switches with eight decoders each
  • One 10 Gb/s uplink per access switch
  • One 1 Gb/s emergency backup link
  • Decoders may select any source

Answer these before reviewing the design:

  1. Maximum media load on each normal uplink: 4.8 Gb/s
  2. Load if all decoders watch one source: 800 Mb/s
  3. Can the 1 Gb/s backup carry all six sources? No
  4. Can it carry one source? Possibly, but with little headroom
  5. Is the system fully redundant? No; it has connectivity backup with severely reduced media capacity

That last distinction belongs in the design narrative.

Compact glossary

  • Traffic matrix: Source, destination and bandwidth relationship.
  • Failure-path load: Traffic carried after a component or link fails.
  • Backplane: Internal switching capacity.
  • Headroom: Capacity reserved beyond calculated traffic.
  • SVI: Layer 3 interface representing a VLAN.
  • PIM: Protocol used to route multicast between subnets.
  • DOM: Optical-module diagnostics such as transmit and receive power.
  • Responsibility matrix: Record of who configures and supports each function.

Review questions

  1. Why is endpoint count insufficient for sizing an AVoIP network?
  2. What is the difference between backup connectivity and functional redundancy?
  3. When should traffic be separated into different VLANs?

Answers

  1. Devices may generate different bitrates, multiple streams, unicast copies or several logical services through one interface.

  2. Backup connectivity only establishes another path. Functional redundancy requires that the path carry the necessary traffic and preserve the required operation.

  3. When separation provides a defined benefit such as security, multicast containment, fault isolation, administrative ownership or manufacturer-required behavior.

Where this sits in the course

This completes the first full networking and AVoIP design arc: fundamentals through practical system engineering.

Continue with Lesson 25 on USB extension and USB-over-IP. For USB 2/3, USB-C, Power Delivery and DisplayPort Alt Mode fundamentals, revisit Lesson 18.