Моя сеть состоит из 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?
Я локализовал эту проблему до локальной сети, воспроизведя сценарий с 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?
