A practical case study on FOH–stage networks, PTP clocking, and real audio redundancy

The Customer Question

A customer reached out with the following issue:

“We are using two NETGEAR M4300 switches with two trunk lines via Auto‑LAG.
Both switches are running the Dante profile.
When we unplug one of the cables, we hear about 2 seconds of audio drop.
When we plug it back in, it sometimes takes 30 seconds before audio returns.
Can we reduce this?”

Technically it looks like a configuration problem — but in reality, it’s an architecture problem.

Auto‑LAG works fine — but not for PTP‑based audio protocols

NETGEAR Auto‑LAG (Auto‑Trunk) automatically bundles multiple physical links into one logical connection.
This works perfectly for:

• Lighting networks (Art‑Net, sACN)
• Show control (OSC, triggers, timecode)
• General IT traffic
• Monitoring
• Control signals

But LACP / Auto‑LAG is not designed for protocols that rely on PTP clocking, such as:

• Dante
• AES67 (used by many modern IP intercom systems like Riedel, Studio Technologies, RTS & Clear-Com)
• ST2110‑30/31 audio

These audio technologies synchronize at microsecond‑level accuracy.
Any trunk or link event inevitably causes:

• PTP resynchronization
• Master re‑election
• Buffer drops
• Audible clicks or audio dropouts

This is why a 1–2 second interruption when a link fails, and 10–30 seconds when it comes back, is completely normal when using LACP.

FOH → Stage: many protocols tolerate a short link drop — but audio does not

The FOH‑to‑stage trunk typically carries a mix of:

• Lighting control
• Show control
• Monitoring
• IT traffic
• Media control
• And of course audio

For most of these workloads except Dante and AES67, the rule is simple:

These protocols do not use PTP and are not affected by short link transitions.

Therefore, Auto‑LAG works extremely well in these scenarios.
For roughly 95% of the traffic, LACP/Auto‑LAG is fast, stable, and sensible.

But not for PTP‑sensitive audio.

What does Audinate say about this?

Audinate is very clear:

Primary and Secondary must be completely separated.

• No shared switches
• No shared VLANs
• No shared trunks
• No shared cabling

Audinate states:

“The Primary and Secondary networks must be completely separate, with no point in common except the Dante devices themselves.”

In other words:

If Primary and Secondary share even one switch, trunk, or cable path, there is NO real Dante or AES67 redundancy.

Real audio redundancy requires separated switches AND separated cable routes

To achieve guaranteed zero‑drop failover, you need two things.

1. Separate switching fabrics

This means:

At least four independent switches

• Primary network: Switch A + Switch B
• Secondary network: Switch C + Switch D

With absolutely NO:

• shared VLANs
• shared LAG
• shared stack
• shared uplinks
• or any other shared element

This is the architecture Dante Redundancy is designed for.

2. Separate physical cable routes

This is still the most commonly overlooked requirement.

If both networks run through the same physical path, one physical incident can take out both networks simultaneously.

Examples:

• Two CAT cables in the same tray
• Two fibers in the same conduit
• Both networks inside the same multicore cable
• A single stage drop that carries everything

Therefore:

✔ Primary via route A

✔ Secondary via route B

✔ Not in the same conduit, tray, or multicore

✔ Ideally separate stage drops

This prevents a single physical issue (strain, a floorplate, moisture, incorrect patching) from wiping out both audio networks at once.

The Practical Conclusion

Auto‑LAG is excellent for

• Lighting
• Show control
• IT traffic
• Monitoring
• FOH → stage combined networks

These traffic types tolerate small link convergence events without issues.

Auto‑LAG is NOT sufficient for

• Dante (PTPv1)
• AES67 (PTPv2)
• IP intercom based on Dante/AES67
• ST2110‑30/31 audio

These protocols require stable PTP clocking and cannot survive link events without audible impact.

Real audio redundancy requires:

• A minimum of four switches
• Separated cable routes
• Separated trunks
• Separated VLANs
• A completely separated switching fabric

➡️ Exactly according to the official Audinate model.

Final Thoughts

The short audio drop the customer experiences is not a malfunction — it is exactly how Auto‑LAG behaves on a shared network.

But once Dante, AES67, or modern IP intercom enters the picture, the rules change.

If you want zero audio loss during failover, the network MUST be:

• logically separated
• physically separated
• and compliant with Dante/AES67 design rules

Anything less is “best effort” —
(with the exception of Video over IP, but that’s a topic for another blog).