K7DJ

混用AES67设备接收端丢包，先查交换机配置再考虑FEC

7 0 老K音网工

直接给结论：先查网络交换机配置，FEC兼容性排在最后。 这不是经验之谈，是底层协议逻辑和现场排障路径决定的。

你看到发送端（Dante）状态正常，说明接口卡芯片没崩，基础时钟也可能锁住了。但AES67是基于标准IP网络的协议，接收端丢包率高，十有八九是数据流在“路上”被交换机给拦截、拥塞或错序了。

为什么交换机配置必须优先排查？

  1. IGMP Snooping 未正确生效：AES67音频流走组播。交换机如果没开IGMP Snooping，或者设备只支持旧版查表，组播流会退化成广播。多开几路音频，交换机背板瞬间打满，接收端NIC队列溢出，表现就是持续丢包。
  2. QoS/DSCP 标记被覆盖：Dante与AES67强制依赖严格的优先级调度。PTP同步包通常标CS6或EF，音频包标CS4。如果接入交换机端口未配置 trust dscp，或策略覆盖，同步报文被当作普通数据排队，时钟抖动（Jitter/RMS）一超标，接收端音频缓冲直接击穿。
  3. PTP 透传或域号冲突：混网最易踩坑。如果中间交换机没开Boundary Transparent Clock，或者不同品牌设备默认PTP Domain不一致（0、124、31等），主从时钟无法收敛。接收端只能靠自由振荡模式硬撑，缓冲策略一旦 mismatch，丢包率自然起飞。
  4. 微突发与端口缓冲：音频包小（通常1ms或1.25ms一包），频率高。普通商用交换机微缓存小，未开启严格优先级队列（Strict Priority）时，突发流量极易造成尾部丢弃（Tail Drop）。

FEC 到底扮演什么角色？为什么不能当主力？
AES67-2015/2018 基础标准并不强制要求 FEC。FEC（前向纠错）多为部分厂商（如Ravenna生态、部分国产音频节点）为应对不可靠网络提供的扩展实现。它的本质是增加冗余校验包。硬开FEC的代价是：

  • 额外增加20%-40%的网络负载，本已满负荷的交换机更扛不住。
  • 算法跨品牌极难互通，接收端若不支持对应FEC封装，会直接静音或报错。
  • 如果底层是时钟不同步或组播路由错误，FEC算不出正确数据，只会徒增延迟。

现场标准排查清单（严格按顺序执行）

  1. 抓包过滤 ptp v2 与UDP 5004 端口。查看 Sync/Announce 报文的 PDV（Packet Delay Variation），若 > 15μs，直接定位网络队列问题，与FEC无关。
  2. 确认全局开启 IGMP Snooping v3，老化时间设为 300s 以上，避免表项频繁刷新导致流中断。
  3. 划定独立音频VLAN，关闭该VLAN内的STP阻塞，PTP跑在二层无环拓扑。
  4. 接入交换机全局启用 QoS，端口信任 DSCP，PTP 映射至最高优先级队列，音频流次之，严格启用 strict-priority-queue。
  5. 核对所有设备 PTP Domain Number、Clock Class 是否为同一主时钟策略下发。

何时才考虑 FEC？
当你确认抓包显示网络层完全无损、PTP 锁定指标优秀、交换机为音频工业级（如 Cisco IE 系列、Koren Pro、Dante 认证型号），且特定品牌接收端说明书明确标注“启用 FEC 可适配非标延迟网络”时，才作为最终兜底手段。但请记住，这属于带病妥协，不是系统健康的标志。

音频网络差几微秒就是爆音。把交换机的组播和时钟逻辑理顺，比折腾协议兼容性有效十倍。

评论

✎