Когда аудио и видео передавались отдельными линиями, неисправность часто искали вдоль одного понятного маршрута: источник, кабель, приемник. Сетевой транспорт добавил общие ресурсы. Два исправных устройства могут оказаться в разных VLAN, поток — не попасть в нужную multicast-группу, а звук — прийти после срока воспроизведения. Поэтому предложение «поменяем коммутатор» появляется слишком рано.
У сетевой AV-системы есть преимущество: многие события можно увидеть и сохранить. Dante Controller показывает состояние устройств, коммутатор — счетчики портов, Wireshark — пакеты в выбранной точке. Разберем последовательность, которая связывает эти наблюдения с конкретным сбоем. В качестве примеров возьмем Dante, NETGEAR M4250 и Cisco CBS350; для другой платформы нужно подобрать ее собственные показатели и команды.
Сначала запишите, что именно пропадает
«Плохо работает сеть» — слишком широкое описание. Запишите, исчезает ли один канал или вся группа, случается ли это при переключении источника, после подключения нового приемника или только во время большой передачи файлов. Нужны точное время, передатчик, приемник и участок пути между ними.
Сравните проблемный приемник с исправным, который получает тот же материал. Если отказ виден на всех выходах одного передатчика, начинайте ближе к источнику. Если только на одной ветви — двигайтесь по ней. Это рабочая гипотеза: общий узел может обслуживать несколько внешне независимых направлений.
Запишите версии прошивок, сохраните схему и счетчики. Не обнуляйте статистику до первого снимка: иначе исчезнет часть истории. Далее сравнивайте прирост за один и тот же интервал, а не абсолютные числа устройств с разным временем работы.
Три программы решают разные задачи
Dante Controller — первый инструмент для системы Dante. У него есть состояние устройств, информация о сети, часах и задержке. Настройки маршрутизации сохраняются в устройствах; наличие открытого окна Controller не является условием передачи звука. Официальное описание Dante Controller.
На поддерживаемом приемнике откройте Device View → Latency. Гистограмма показывает распределение времени прихода аудиопакетов относительно допустимой задержки. Красная область указывает на поздний приход; увеличение буфера может убрать выпадения, но добавит задержку. Для Dante AV эта настройка относится к аудиоканалам, поэтому по ней нельзя оценить всю видеозадержку. Руководство: Latency Tab.
Сам Controller не перехватывает аудиопакеты: измерения делает приемное устройство, а программа запрашивает его статистику. Гистограмма не показывает полный перечень пакетов, которые вообще не дошли до приемника. Пояснение Dante Support.
Wireshark нужен, когда требуется изучить обмен в определенной точке: приходит ли multicast, какие сообщения синхронизации видны, есть ли разрывы последовательности RTP. Для распознанного RTP раздел Telephony → RTP → Stream Analysis показывает задержки между пакетами, jitter и число потерь, рассчитанное по номерам последовательности. Это описание захваченного потока. Потеря пакета самим компьютером захвата тоже может исказить вывод. RTP в руководстве Wireshark.
iperf3 создает тестовый TCP- или UDP-трафик между двумя компьютерами. Он помогает отдельно исследовать пропускную способность и поведение выбранного маршрута под нагрузкой. Это активный тест: величину потока и время согласуют заранее, особенно в работающей системе. Успешный тест между двумя ПК не подтверждает корректность PTP, всех multicast-подписок или работы конкретного кодера. Документация iperf3.
На коммутаторе различайте ошибки и отбрасывания
Сначала проверьте фактическую скорость соединения, изменения состояния линка и ошибки приема. Затем — отброшенные пакеты, загрузку выходов и очереди, если модель их показывает. Порт может иметь устойчивое соединение и при этом не успевать передавать весь поступающий поток.
На NETGEAR M4250 в основном интерфейсе руководства для firmware 13.x статистика находится в Monitoring → Ports → Port Statistics; рядом есть подробная статистика выбранного порта. Ищите Packets Received With Error, Link Down Events и Link Flaps. В подробной таблице Receive Packets Discarded отделены от MAC/FCS Errors: пакет может быть отброшен без ошибки самого кадра, например при нехватке буфера. M4250 Main User Manual, раздел статистики портов.
Представим учебную ситуацию: после подключения еще одного видеоприемника у выходного порта растут discards, а FCS-ошибки остаются на прежнем уровне. Это основание проверить распределение потоков и нагрузку на данном выходе. Менять кабель только по факту роста discards было бы поспешно. Обратная картина — рост ошибок кадров и переключения линка — направляет внимание к физическому соединению и портам.
Средняя загрузка за длинный интервал может скрыть короткие всплески. Сопоставляйте счетчики очередей, более частые измерения и время симптома. Если нужной телеметрии нет, так и запишите: отсутствие показателя не означает отсутствие перегрузки.
Multicast проверяйте по группе и выходному порту
Начните с адреса конкретной группы и списка приемников. Проверьте VLAN передатчика и приемника, наличие подписки и фактические порты доставки. Включенная галочка IGMP snooping сама по себе не отвечает на вопрос, куда сегодня идет нужный поток.
На Cisco CBS350 руководство дает команду чтения:
text show ip igmp snooping groups
Она показывает группы, изученные механизмом snooping; параметры позволяют ограничить вывод VLAN, адресом группы и источником. Например, документированный вариант show ip igmp snooping groups vlan 100 относится к VLAN 100, если именно она используется в вашей системе. CBS350: IGMP Snooping Commands.
Сохраните таблицу до подписки, после нее и в момент отказа. Затем сравните с тем, что видит приемник. Исчезновение группы после некоторого времени требует проверки запросов IGMP, времени жизни записей и связи с querier. Не начинайте с одновременного изменения snooping, VLAN и multicast-фильтров: такое исправление будет трудно объяснить и повторить.
Синхронизацию рассматривайте отдельно от доставки
Для Dante посмотрите Clock Status и историю событий. Текущая документация различает, в частности, Follower, Listening и Leader. Follower означает синхронизацию с ведущими часами; Listening — ожидание подходящего источника синхронизации. Само состояние Leader не доказывает, что остальные устройства получают его сообщения. Состояния часов Dante.
Смена ведущих часов при включении оборудования может быть обычным этапом выбора. Важнее, стабилизировалась ли система после запуска и совпадает ли последующая смена с пропаданием звука. Логи Controller нужно собирать во время наблюдения: они не превращаются в полную историю всех прежних событий только после запуска программы. Официальный учебный разбор Controller.
Не переносите настройки часов одного медиатранспорта на другой по похожему названию PTP. У платформ могут различаться версии, профили и требования к сетевому оборудованию. Сначала выясните, какой режим использует конкретный комплект.
Захват пакетов должен отвечать на один вопрос
Определите, что хотите доказать: «поток не дошел до порта приемника», «изменился источник часов» или «в RTP появились разрывы». Выберите точку наблюдения и проверьте, способен ли компьютер захвата принять скопированный трафик. Обычный ноутбук в соседнем порту коммутатора не видит автоматически весь чужой unicast-трафик.
Для сложного случая полезны две согласованные точки — ближе к передатчику и приемнику. Укажите в отчете порт, направление копирования, время, фильтры и потери самого захвата. В Wireshark сохраните исходный pcapng и условия его получения. Для вывода о пакетных потерях нужны данные о том, как был записан файл, а не только красная строка анализа.
Уровень QoS рассматривайте после определения платформы и пути. Приоритет очереди может защитить чувствительные пакеты при конкуренции, но не добавляет физическую пропускную способность выходному порту. Если несколько нужных потоков постоянно превышают его возможности, понадобится изменить распределение или емкость системы.
Короткий маршрут проверки
1. Назовите симптом, время, поток, передатчик и приемник. 2. Сохраните схему и исходные счетчики, затем измеряйте их прирост. 3. Проверьте линк и ошибки кадров; отдельно — discards и перегруженные выходы. 4. Для multicast сравните группу, VLAN, подписку и порты доставки. 5. Проверьте состояние часов и опоздания пакетов средствами своей платформы. 6. При необходимости снимите целевой захват; активную нагрузочную пробу выполняйте отдельно и по согласованному плану. 7. Измените один фактор, повторите исходный сценарий и сохраните результат.
Для приемки исправления нужен тот же рабочий режим, в котором возникал сбой: полный набор потоков, обычные переключения и характерная нагрузка. Запишите длительность наблюдения и ограничения проверки. Фраза «час работало без выпадений при таких условиях» полезнее обещания, что сеть больше никогда не даст сбой.