Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Проблемы с пропаданием потока при приеме UDP на UDR. #UDR #UDP #Streaming #Audio #Latency, wifiman
 
Моя сеть состоит из UDR, к которому через mesh-соединение подключен один U6 Pro для увеличения зоны покрытия и предоставления ethernet-порта для устройства. Wi-Fi сеть – одна SSID с 3 PSK для разных VLAN, доступна как на 5 ГГц, так и на 2.4 ГГц. Все работало без проблем около года, но недавно заметил прерывистые сбои в видеозвонках в реальном времени (meet, zoom, gather и т.д.), при которых другие меня видят, но я – их нет. При этом пинги до интернета остаются непрерывными во время этих сбоев.

Я локализовал эту проблему до локальной сети, воспроизведя сценарий с iperf-сервером на устройстве, подключенном по ethernet к UDR: [server] <--eth--> [UDR] <--5 GHz--> [client]

Клиент – Macbook, находящийся в нескольких футах от UDR, подключенный по 5 ГГц, работает с двунаправленным UDP iperf до сервера: iperf3 -u -c server1 --bidir -t 9999 -b 10M

Это работает нормально сначала, но через несколько минут клиент внезапно перестает видеть принимаемые пакеты, в то время как сервер все еще видит трафик с обеих сторон. После этого состояние не восстанавливается, даже несмотря на то, что пинги до сервера продолжают проходить. Кроме того, при запуске нескольких параллельных двунаправленных iperf-сессий с одного беспроводного клиента к нескольким серверам или на разных портах, через несколько минут прием пакетов прекращается в одной из клиентских сессий. Затем в другой. Затем в третьей. Не одновременно! Таким образом, беспроводное соединение клиента с UDR все еще работает, но отдельные потоки принимаемых пакетов постепенно умирают.

Это не проблема QoS или нагрузки, поскольку пропускные способности потоков низкие (10 Мбит/с) по отношению к короткому каналу 5 ГГц (500+ Мбит/с), и все потоки проходят параллельно без сбоев в течение первых нескольких минут. Если отключить радио 2.4 ГГц, чтобы UDR работал только на 5 ГГц, проблему воспроизвести не удается.

Похоже, что таблица перенаправления пакетов UDR повреждается для отдельного хэша заголовка, поскольку потеря очень бинарна (все работает, пока внезапно не перестает), она влияет только на одно направление одного кортежа потока (ip:порт -> ip:порт) одновременно, только когда трафик идет по Wi-Fi и только когда активны несколько радиомодулей.

Я думаю, что мой UDR обновился до приложения Network 9.0.108 незадолго до того, как я начал замечать эти проблемы, поэтому я естественно подозреваю проблему с новой прошивкой, но мне не хочется ее откатывать, чтобы это исправить. Я не трогал новые функции брандмауэра, могу, если потребуется. Пока что я обходим проблему, отключая 2.4 ГГц, но это отключает некоторые мои IoT-устройства.

Сталкивался ли кто-нибудь с чем-то подобным? Какие шаги по устранению неполадок перед тем, как я попытаюсь откатить приложение Network?
 
Я добавил отдельный SSID только на 2.4 GHz, но это вернуло проблемы с потерей стрима на SSID 2.4 GHz. Мне *нужно*, чтобы что-то работало на 2.4 GHz, чтобы мое старое оборудование и устройства умного дома были онлайн, поэтому я отключил свой UDR, и SSID 2.4 GHz теперь размещается только на моем mesh U6 Pro AP. Это снова решило проблему. Очевидно, что-то не работает с моим UDR, из-за чего радио 2.4 GHz бесполезно. Я очень подозреваю, что это вызвано изменениями в Network 9.0.108, но поскольку сейчас все более-менее работает, я, возможно, не займусь дальнейшей диагностикой самостоятельно. Однако я очень опытен в отладке прошивок коммутаторов, поэтому, если кто-то из UBNT захочет связаться, я с удовольствием покопаюсь в этом глубже.
 
Пинги продолжают циркулировать между клиентом и сервером постоянно, несмотря ни на что. В случае, который я тестировал, да, UDR маршрутизирует, потому что сервер находится в другой подсети. Но это интересный вопрос, поэтому я попробую поместить сервер в ту же подсеть с клиентом, чтобы свести это только к проблеме уровня 2.

Что меня удивляет, так это то, что другие потоки продолжают работать даже тогда, когда один умирает. Они постепенно, поодиночке, отказывают, один за другим, в течение нескольких минут, а пинги продолжают циркулировать. Так что я уверен, что UDR не теряет ARP-запись. Это очень сильно специфично для потока, что заставляет меня думать о flow/hash table. (Я раньше разрабатывал большие L3-коммутаторы, так что, конечно, думаю о повреждении TCAM).

Да, я собираюсь создать следующую SSID только на 2.4 ГГц и посмотреть, как это будет работать, хотя бы для того, чтобы снова включить мои IoT-устройства.

Спасибо за все идеи! Просто здорово подискутировать и убедиться, что я ничего глупого не забыл.
 
Это значит, что ещё какая-то отдельная проверка ICMP работает? Это может быть полезно, потому что ping использует ICMP-сообщения (а не UDP), и было бы интересно, если бы ping тоже прекращался одновременно — это помогло бы определить, действительно ли проблема в повреждении таблицы маршрутизации.

Но вернёмся к проблеме с таблицей потоков: что делает UDR для этих пакетов — то есть, клиент и сервер находятся в разных IP-сетях (и UDR маршрутизирует, возможно, затрагивая и правило iptables) или они в одной IP-сети (и UDR просто переключает трафик)?

Пока что проблема ощущается как потеря UDR-ом записи ARP. Что, конечно, странно. Когда работает 5ГГц+2.4ГГц, к какой частоте подключается клиент?

Для диагностики, возможно, стоит временно создать три новых SSID: только 2.4ГГц, только 5ГГц и сеть 2.4+5ГГц.
Страницы: 1
Читают тему (гостей: 1)