Машины не подключаются к ближайшей точке доступа.

Машины не подключаются к ближайшей точке доступа., wifiman

daniel.mcmanus

Guest

04.10.2023 20:04:00

Привет, ищу совет, если возможно. У нас на этаже в офисе стоит 8 точек доступа (6xU6 Enterprise и 2x IW6). Постоянно сталкиваемся с проблемами производительности на устройствах, которые подключаются к точкам доступа, находящимся далеко от них. Из-за этого сигнал слабый, а производительность падает. После нескольких перезапусков WiFi на устройстве оно в итоге выбирает самую сильную точку доступа, и signal strength и производительность становятся нормальными.

Все точки доступа настроены на 20 МГц в диапазоне 2,4 ГГц с мощностью передачи 6 (минимально возможная), и 40 МГц на 5 ГГц также с мощностью передачи 6 дБм. Каналы сейчас выставлены на Auto. Роуминг практически не происходит — устройства слишком долго держатся за одну точку доступа, из-за чего пользователям приходится вручную переподключаться в надежде, что выберется правильная точка.

Стоит отметить, что 99% этих клиентов — MacBook, у которых включен режим “join mode” на «strongest», как я нашёл в рекомендациях. Быстрый роуминг тоже отключён.

Понимаю, что в конечном итоге решение, к какой точке подключиться, принимает клиент, но интересно, возможно ли что-то изменить в настройках нашей сети? Буду очень благодарен за любую помощь!

daniel.mcmanus

Guest

07.11.2023 21:37:00

Изначально казалось, что в этом и была проблема. Устройства подключались к точкам доступа в неправильных местах, но после того, как мы снизили мощность и вручную настроили каналы, это почти не происходит. Однако теперь мы замечаем проблемы с производительностью даже при подключении к так называемой «правильной» точке доступа, судя по уровню сигнала и другим параметрам. Кажется, что это происходит случайным образом на короткие периоды, когда производительность внезапно падает примерно на 5 минут, а потом восстанавливается сама собой.

RobbieH Guest	#3 07.11.2023 20:15:00 Есть большая разница между проблемой с тем, что клиенты плохо переключаются между точками доступа, и ситуацией, когда точки доступа начинают глючить при наличии более 30 клиентов на одной точке.

its3am

Guest

07.11.2023 20:13:00

В общем, то, с чем вы сталкиваетесь — это потеря связи, когда все становится более загруженным. У меня была такая же проблема на площадках во время мероприятий (не моих, поэтому подробностей нет, кроме того, что там использовали UAP-HD). Надеюсь, UI сможет разобраться в ситуации.

daniel.mcmanus Guest	#5 07.11.2023 09:16:00 @UI-Glenn Привет, Гленн! Я загрузил наши лог-файлы, когда у нас были серьёзные проблемы с падением производительности сети по Wi-Fi. Хотелось бы узнать, сможешь ли ты чем-то помочь. Заранее спасибо!

daniel.mcmanus Guest	#6 07.11.2023 09:14:00 Отлично, я так и сделаю! У меня есть файл поддержки с того дня, когда возникли проблемы, так что я с этим разберусь. Большое спасибо!

daniel.mcmanus

Guest

07.11.2023 09:13:00

Это было сделано через локальный IP-шлюз в браузере, а не через ubnt.ui.com, когда я был подключён по Wi-Fi, а не через кабель Ethernet. К тому времени, как я дошёл до консоли, чтобы подключиться через Ethernet, производительность уже улучшилась.

gregorio Guest	#8 06.11.2023 16:09:00 В такие времена было бы неплохо сохранить файл поддержки и загрузить его в свой исходный пост, сделав приватным. Затем отметь UI-Glenn.

its3am

Guest

06.11.2023 14:00:00

Я не понимаю, что это значит. Вы имели в виду подключение через Ethernet-кабель, минуя WiFi? Тогда проблема не в WiFi-сети, а либо в UDM, либо в сети провайдера. Возможных объяснений масса — от проблем с MTU и DNS до мультипатинга или любых других неправильных настроек.

daniel.mcmanus

Guest

#10

06.11.2023 09:30:00

Всем привет! Просто хочу ещё раз поднять эту тему, так как проблемы всё ещё есть.

На всех AP задана низкая мощность, каналы не перекрываются (все выставлены вручную после сканирования RF).

В консоли UniFi почти не видно устройств с сигналом хуже -62 дБм, но периодически возникают проблемы с производительностью: скорость сети резко падает (страницы не загружаются и т.п.). Количество клиентов может варьироваться от 80 до 180 в напряжённый день. Некоторые точки доступа одновременно обслуживают до 35 устройств.

На прошлой неделе была ситуация: у одних пользователей всё работало нормально, они могли говорить по звонкам, а другие вообще не могли загрузить страницы. Даже когда я подключался к UDM по локальному IP, страницы не открывались. При этом загрузка CPU, RAM и других показателей была в норме, когда я всё-таки подключался — ничего необычного не замечал. Полностью теряюсь, что именно происходит.

Буду благодарен за любую помощь! Также связался с нашим провайдером — попросил проверить, нет ли перегрузки на нашей линии. В офис у нас сейчас подключён 1 Гбит канал.

Спасибо!

daniel.mcmanus

Guest

#11

08.11.2023 18:30:00

После небольшого дополнительного расследования сегодня, похоже, что проблема, с которой мы сталкиваемся, возможно связана с плохой задержкой до точек доступа (AP). Уровень сигнала хороший, ниже -60 дБм. Но при тесте задержки примерно каждые 30 секунд наблюдаются прыжки. Пинг до AP показывает похожие результаты, а также иногда теряются пакеты — примерно раз в пару минут. Кто-нибудь ещё сталкивался с таким?

PING 10.0.1.163 (10.0.1.163): 56 data bytes
64 bytes from 10.0.1.163: icmp_seq=0 ttl=64 time=5.878 ms
64 bytes from 10.0.1.163: icmp_seq=1 ttl=64 time=4.742 ms
64 bytes from 10.0.1.163: icmp_seq=2 ttl=64 time=3.455 ms
64 bytes from 10.0.1.163: icmp_seq=3 ttl=64 time=7.892 ms
64 bytes from 10.0.1.163: icmp_seq=4 ttl=64 time=7.114 ms
64 bytes from 10.0.1.163: icmp_seq=5 ttl=64 time=35.763 ms
64 bytes from 10.0.1.163: icmp_seq=6 ttl=64 time=82.875 ms
64 bytes from 10.0.1.163: icmp_seq=7 ttl=64 time=5.129 ms
64 bytes from 10.0.1.163: icmp_seq=8 ttl=64 time=8.291 ms
64 bytes from 10.0.1.163: icmp_seq=9 ttl=64 time=26.140 ms
64 bytes from 10.0.1.163: icmp_seq=10 ttl=64 time=71.711 ms
64 bytes from 10.0.1.163: icmp_seq=11 ttl=64 time=5.726 ms
64 bytes from 10.0.1.163: icmp_seq=12 ttl=64 time=8.105 ms
64 bytes from 10.0.1.163: icmp_seq=13 ttl=64 time=3.024 ms
64 bytes from 10.0.1.163: icmp_seq=14 ttl=64 time=3.434 ms
64 bytes from 10.0.1.163: icmp_seq=15 ttl=64 time=7.667 ms
64 bytes from 10.0.1.163: icmp_seq=16 ttl=64 time=4.287 ms
64 bytes from 10.0.1.163: icmp_seq=17 ttl=64 time=44.272 ms
64 bytes from 10.0.1.163: icmp_seq=18 ttl=64 time=87.039 ms
64 bytes from 10.0.1.163: icmp_seq=19 ttl=64 time=5.226 ms
64 bytes from 10.0.1.163: icmp_seq=20 ttl=64 time=6.382 ms
64 bytes from 10.0.1.163: icmp_seq=21 ttl=64 time=38.751 ms
64 bytes from 10.0.1.163: icmp_seq=22 ttl=64 time=3.198 ms
64 bytes from 10.0.1.163: icmp_seq=23 ttl=64 time=6.357 ms
64 bytes from 10.0.1.163: icmp_seq=24 ttl=64 time=9.565 ms
64 bytes from 10.0.1.163: icmp_seq=25 ttl=64 time=19.569 ms
64 bytes from 10.0.1.163: icmp_seq=26 ttl=64 time=58.040 ms
64 bytes from 10.0.1.163: icmp_seq=27 ttl=64 time=97.808 ms
64 bytes from 10.0.1.163: icmp_seq=28 ttl=64 time=4.179 ms
64 bytes from 10.0.1.163: icmp_seq=29 ttl=64 time=6.876 ms
64 bytes from 10.0.1.163: icmp_seq=30 ttl=64 time=3.761 ms
64 bytes from 10.0.1.163: icmp_seq=31 ttl=64 time=4.428 ms
64 bytes from 10.0.1.163: icmp_seq=32 ttl=64 time=10.356 ms
64 bytes from 10.0.1.163: icmp_seq=33 ttl=64 time=4.329 ms
64 bytes from 10.0.1.163: icmp_seq=34 ttl=64 time=44.599 ms
64 bytes from 10.0.1.163: icmp_seq=35 ttl=64 time=102.579 ms
64 bytes from 10.0.1.163: icmp_seq=36 ttl=64 time=144.595 ms
64 bytes from 10.0.1.163: icmp_seq=37 ttl=64 time=9.629 ms
64 bytes from 10.0.1.163: icmp_seq=38 ttl=64 time=7.674 ms
64 bytes from 10.0.1.163: icmp_seq=39 ttl=64 time=4.277 ms
Request timeout for icmp_seq 40
64 bytes from 10.0.1.163: icmp_seq=41 ttl=64 time=2.749 ms
Request timeout for icmp_seq 42
64 bytes from 10.0.1.163: icmp_seq=43 ttl=64 time=4.295 ms
64 bytes from 10.0.1.163: icmp_seq=44 ttl=64 time=62.345 ms
64 bytes from 10.0.1.163: icmp_seq=45 ttl=64 time=87.108 ms
64 bytes from 10.0.1.163: icmp_seq=46 ttl=64 time=131.891 ms
64 bytes from 10.0.1.163: icmp_seq=47 ttl=64 time=8.801 ms
64 bytes from 10.0.1.163: icmp_seq=48 ttl=64 time=6.889 ms
64 bytes from 10.0.1.163: icmp_seq=49 ttl=64 time=5.086 ms
64 bytes from 10.0.1.163: icmp_seq=50 ttl=64 time=4.222 ms
64 bytes from 10.0.1.163: icmp_seq=51 ttl=64 time=5.862 ms
64 bytes from 10.0.1.163: icmp_seq=52 ttl=64 time=9.822 ms
64 bytes from 10.0.1.163: icmp_seq=53 ttl=64 time=6.364 ms
64 bytes from 10.0.1.163: icmp_seq=54 ttl=64 time=52.379 ms
64 bytes from 10.0.1.163: icmp_seq=55 ttl=64 time=89.903 ms
64 bytes от 10.0.1.163: icmp_seq=56 ttl=64 time=127.845 ms
64 bytes от 10.0.1.163: icmp_seq=57 ttl=64 time=5.073 ms
64 bytes от 10.0.1.163: icmp_seq=58 ttl=64 time=5.897 ms
64 bytes от 10.0.1.163: icmp_seq=59 ttl=64 time=7.827 ms
64 bytes от 10.0.1.163: icmp_seq=60 ttl=64 time=12.861 ms
64 bytes от 10.0.1.163: icmp_seq=61 ttl=64 time=4.441 ms
64 bytes от 10.0.1.163: icmp_seq=62 ttl=64 time=7.388 ms
64 bytes от 10.0.1.163: icmp_seq=63 ttl=64 time=10.519 ms
64 bytes от 10.0.1.163: icmp_seq=64 ttl=64 time=7.657 ms
64 bytes от 10.0.1.163: icmp_seq=65 ttl=64 time=2.583 ms
64 bytes от 10.0.1.163: icmp_seq=66 ttl=64 time=7.777 ms
64 bytes от 10.0.1.163: icmp_seq=67 ttl=64 time=17.707 ms
64 bytes от 10.0.1.163: icmp_seq=68 ttl=64 time=7.557 ms
64 bytes от 10.0.1.163: icmp_seq=69 ttl=64 time=3.625 ms
64 bytes от 10.0.1.163: icmp_seq=70 ttl=64 time=9.279 ms
64 bytes от 10.0.1.163: icmp_seq=71 ttl=64 time=3.241 ms
64 bytes от 10.0.1.163: icmp_seq=72 ttl=64 time=7.468 ms
64 bytes от 10.0.1.163: icmp_seq=73 ttl=64 time=4.888 ms
64 bytes от 10.0.1.163: icmp_seq=74 ttl=64 time=3.950 ms
64 bytes от 10.0.1.163: icmp_seq=75 ttl=64 time=3.476 ms
64 bytes от 10.0.1.163: icmp_seq=76 ttl=64 time=7.373 ms
64 bytes от 10.0.1.163: icmp_seq=77 ttl=64 time=9.257 ms
64 bytes от 10.0.1.163: icmp_seq=78 ttl=64 time=10.963 ms
64 bytes от 10.0.1.163: icmp_seq=79 ttl=64 time=3.731 ms
64 bytes от 10.0.1.163: icmp_seq=80 ttl=64 time=8.197 ms
64 bytes от 10.0.1.163: icmp_seq=81 ttl=64 time=4.474 ms
64 bytes от 10.0.1.163: icmp_seq=82 ttl=64 time=5.756 ms
64 bytes от 10.0.1.163: icmp_seq=83 ttl=64 time=14.851 ms
64 bytes от 10.0.1.163: icmp_seq=84 ttl=64 time=3.449 ms
64 bytes от 10.0.1.163: icmp_seq=85 ttl=64 time=7.180 ms
64 bytes от 10.0.1.163: icmp_seq=86 ttl=64 time=3.234 ms
^C
--- 10.0.1.163 ping statistics ---
87 пакетов передано, 85 пакетов получено, потеря 2.3% пакетов
время в пути min/среднее/max/стандартное отклонение = 2.583/21.552/144.595/32.832 мс

daniel.mcmanus Guest	#12 07.11.2023 21:59:00 Извините, возможно, я не упоминал об этом. Но да, всё верно, оба теперь выключены.

RobbieH Guest	#13 07.11.2023 21:46:00 Извини, если пропустил — я пересмотрел и ничего не заметил. Сейчас функция band steering и минимальное значение RSSI выключены?

Читают тему (гостей: 1)