Проблемы с тайм-аутом DHCP

Проблемы с тайм-аутом DHCP, UniFi Network

etincelle

Guest

11.04.2019 21:03:00

Создаю новую тему, потому что уже несколько месяцев у некоторых устройств в сети (Sonos, Chromecast, некоторые ПК, работающие машины и т.д.) реальные проблемы с таймаутом DHCP, о чём обсуждается во многих разных темах и у разных людей.

Установка: полная Unifi с
- USG PRO4 в роли шлюза и DHCP-сервера
- Switch PRO 48 POE 750W
- Switch PRO 48 (связь по 10 Gb оптикой)
- 2 AP HD
- 11 AP PRO
- 1 AP MESH на улице

Всё работает отлично, кроме этого чёртова таймаута DHCP на множестве устройств!

@AmazedMender16, если есть идеи...

gr1nch

Guest

02.09.2021 16:10:00

В моей сети тоже постоянно происходят тайм-ауты DHCP на разных устройствах (5 ГГц и 2,4 ГГц) с 2 UAP-AC-LR и одним UAP-AC-M. Все они обновлялись в течение примерно 6 месяцев по мере выхода новых прошивок, но некоторые устройства, у которых проблем с получением DHCP в сетях не-Unifi вообще нет, в моей Unifi-сети с арендой IP порой приходится сильно повозиться, а иногда это вообще невозможно. Теперь я задумываюсь, сколько денег смогу вернуть, если избавлюсь от всей техники Unifi и поставлю нормальную Mesh-систему, которая делает все, что нужно, без попыток быть слишком умной и красивой, но при этом не справляется с базовыми вещами.

schieble Guest	#3 07.07.2021 22:34:00 По всей видимости, решение, предложенное Ubiquiti в этой ветке 5 месяцев назад, заключалось в обновлении прошивки до версии 4.3.28, но оно не исправляет проблему, по крайней мере в моих случаях.

phil45

Guest

21.02.2021 19:06:00

У меня такая же проблема с двумя AC-Lite на версии 4.3.20.11298. Клиенты, переключающиеся между точками доступа, не получают IP-адрес. Я подозреваю, что работы по улучшению совместимости с DHCP от сторонних производителей не решили проблему для всех реализаций DHCP, потому что у нас на работе около 200 AC-HD с Windows DHCP — и там всё работает нормально. Но в моей домашней сети, где DHCP ведёт роутер BT Homehub, всё очень ненадёжно. Поскольку моя семья уже готовится выгнать меня за плохой Wi-Fi, кто-нибудь знает, будет ли работать лучше, если DHCP будет обрабатывать Unifi Security Gateway?

alexbligh

Guest

29.12.2020 23:34:00

Еще один случай. Недавнее обновление AP до версии 4.3.24.11355 стабильно вызывало проблемы на MacBook Pro 2013 года с OS-X 10.11.6. tcpdump на Mac показывал, что устройство отправляет DHCP-сообщения Discover, но не получает ответа. DHCP-сервер (Mikrotik) вроде бы получал эти Discover-пакеты и отправлял ответ. Если оставить устройство на 10-20 минут, оно иногда получало аренду. Ручное понижение версии до 4.3.20.11298, похоже, решает проблему, и теперь оно получает аренду мгновенно.

Обратите внимание, что DHCP snooping у меня включен (был включен и до проблемы, отключение не помогло), а опция Block LAN to WLAN Multicast and Broadcast Data постоянно выключена.

В заметках к промежуточному релизу 4.3.21 я заметил следующее:
[UAP] Исправлена потенциальная проблема стабильности с DNS-перенаправлением на UAP с гостевыми сетями.
У меня гостевая сеть не работает, и это единственное изменение, связанное с DNS. (зачеркнуто, так как я понял, что был слишком уставшим, чтобы правильно различать DNS и DHCP)

Поскольку проблема повторяется, я создал новую тему здесь с более подробной информацией, вместо того чтобы добавлять в двухлетнюю ветку с 200 ответами, где обсуждается несколько разных проблем.

jrickman

Guest

28.12.2020 15:55:00

У меня есть клиент, у которого появилось много проблем после того, как я обновил прошивку на точках доступа до версии 4.3.24.11355. Я только что вернул их точки доступа на версию 4.3.20.11298 благодаря этой странице. Сейчас пробую, спасибо.

STEFKA

Guest

17.12.2020 13:31:00

У нас была та же проблема на установке с 14 AP (Pro gen2). Сотни таймаутов DHCP в логах UAP (mcad[18095]: wireless_agg_stats.log_sta_anomalies(): bssid=XXXXX radio=wifi0 vap=ath0 sta=XXXXXX satisfaction_now=0 anomalies=ip_timeout dhcp=r). Понизили версию с "4.3.24.11355" до "4.3.20.11298" — и всё снова работает нормально. С тех пор ни одного таймаута DHCP.

martynw2000

Guest

17.12.2020 09:05:00

Эта проблема, похоже, повторилась у нас 6 дней назад, когда на всех наших точках доступа (у нас их 8 штук UAP-AC-Pro) автоматически обновилась прошивка. Много таймаутов и ошибок DHCP, из-за чего пользователи Wi-Fi не могли подключиться к сети. Проводные пользователи работали нормально, и те, у кого был статический IP, тоже не испытывали проблем, так что проблема точно была с Wi-Fi. Перезагрузка точек доступа давала результат примерно на 30-40 минут, после чего они снова начинали отказывать в раздаче DHCP. Проблемная прошивка — версия 4.3.24, выпущенная 07-12-2020. Мы решили проблему, отключив автоматические обновления и откатив все точки доступа до версии 4.3.20, выпущенной 07-07-2020. Все версии прошивок можно найти здесь: https://www.ui.com/download/unifi/unifi-ap-ac-pro Надеюсь, это поможет.

kashif-ali Guest	#9 25.11.2020 16:14:00 Привет, я изменил время аренды DHCP на 84600 (1 день), и всё начало работать нормально. Обновил прошивку обратно до последней версии — всё по-прежнему работает отлично.

raiden81

Guest

#10

17.03.2020 21:08:00

Я обновил все точки доступа и коммутаторы до версии 4.3.6.11207, но это не помогло. После этого я подключил все точки доступа с 48-портового PoE коммутатора к 8-портовому PoE коммутатору, и теперь всё работает уже три дня. Так что, на мой взгляд, проблема именно в 48-портовом PoE коммутаторе. Если найду время, попробую сделать сброс настроек коммутатора до заводских.

rhloven Guest	#11 12.03.2020 11:17:00 @bingold, попробуй обновить свои приложения до последней бета-версии прошивки. Похоже, это помогает некоторым людям с этой проблемой.

raiden81

Guest

#12

11.03.2020 18:50:00

High Performance Devices неактивны в моей сети. Я пробовал разные способы, но без успеха, или это было лишь временным решением после смены статуса Provision. В моей сети это происходит почти каждый день: после перезагрузки 48-портового свича всё некоторое время работает снова, но, думаю, это больше из-за того, что все UniFi AP-AC Pro питаются от POE этого свича.

Проблему я никогда не видел у проводных клиентов, и она появилась после обновления прошивки (апрель, полгода назад).

В моей сети такие UniFi-устройства:
· 1x UniFi Security Gateway (4.4.50.5272479)
· 1x UniFi Switch 48 POE-750 (4.0.80.10875)
· 1x UniFi Switch Flex (4.0.80.10875)
· 1x UniFi Switch 8 POE-150 (4.0.80.10875)
· 2x UniFi Switch 8 (4.0.80.10875)
· 5x UniFi AP-AC-Pro (4.0.80.10875)

Я сделал несколько настроек, чтобы найти источник проблемы. Иногда после provisioning всё на время снова начинает работать. Эта проблема очень раздражает, потому что влияет на мой умный дом. Если её не починят в ближайшее время, всерьёз подумываю сменить бренд.

Kalidan Guest	#13 05.03.2020 20:13:00 Мне удалось решить проблему, отключив "High Performance DevicesConnects high performance clients to 5 GHz only" в Настройки > Беспроводная сеть. Надеюсь, это кому-то поможет... использую Cloud Key версии 5.12.35-12979-1.

frankrellis

Guest

#14

16.02.2020 03:36:00

Попробуйте отключить IGMP Snooping в сети на контроллерах Unifi для любых коммутаторов Unifi, которые могут быть в кольце. Я заметил, что это значительно повысило общую стабильность моей сети и предотвратило помехи со стороны коммутаторов Unifi в работе DHCP/DNS.

shaicc

Guest

#15

03.02.2020 16:15:00

Привет, я столкнулся с похожими проблемами после обновления моих устройств — двух Unifi AP и Switch 8s до версии 4.0.80. Также одновременно обновил контроллер до версии 5.12.35.

Что я заметил на панели управления:
Высокий показатель времени ожидания/сбоев WPA аутентификации — 287
Высокий показатель времени ожидания/сбоев DHCP — 433

В статистике:
Высокое количество повторных передач (TX retries) на моем AC-AP Pro — 181220%

Первоначальные действия:
Я пытался откатиться на 4.0.69, но проблема с высокими таймаутами DHCP, сбоями WPA аутентификации и большим количеством повторных передач сохранилась.

Небольшая предыстория по 4.0.69:
На версии 4.0.69 я тоже замечал высокие значения WPA аутентификации и повторных передач, но не был высоким уровень таймаутов DHCP. Тогда для решения я сделал следующее:
1) На каждом из AP уменьшил мощность радио WLAN:
5G: с высокого уровня до среднего
2G: со среднего до низкого
2) Изменил канал WLAN с автоматического на конкретный
3) DTIM изменил с дефолтного 1 на 3

Что я заметил после новых обновлений:
Полагаю, что новая версия контроллера 5.12.35 ввела функцию Auto Optimize, которая автоматически выставляет уровни мощности WLAN в режим Auto вместо моих прежних настроек — Medium на 5G и Low на 2G.

Ниже то, что, как мне кажется, сейчас работает:
Честно говоря, после отката на 4.0.69 я просто сделал:
1) Отключил Auto Optimize
2) На каждом AP установил мощность радио WLAN:
5G: с Auto на Medium
2G: с Auto на Low
3) DTIM: с 1 на 3

И в течение дня таймауты DHCP резко уменьшились и продолжают снижаться. Также снизились ошибки WPA аутентификации и количество повторных передач на моём AP_AC_Pro — были 181220%, теперь 34885%, и продолжают падать уже три дня подряд.

Думаю, что не сама версия прошивки вызывает проблему, а именно новая версия контроллера с Auto Optimize, которая сбила мои предыдущие настройки, сделанные на 4.0.69.

Когда ситуация полностью стабилизируется и повторные передачи упадут до нормальных значений, планирую снова обновить устройства до 4.0.80 и посмотреть, не появится ли что-то новое.

vertices

Guest

#16

03.02.2020 14:58:00

Мы демонтировали беспроводные решения Ubiquiti, которые сами продавали, вернули их поставщику и за свой счёт заменили на Meraki. Для нас гораздо важнее бизнес MSP клиента, и мы не хотели терять его из-за проблем с беспроводной связью. После этого мы вообще перестали продавать Ubiquiti, даже как бюджетное решение.

Я всё ещё слежу за ситуацией и рассматриваю возможность вернуть Ubiquiti в наш портфель как базовое решение для маленьких установок с 1-4 точками доступа, но только когда буду уверен, что проблемы решаются. А вот этот DHCP-баг тянется уже долго, и честно говоря, не знаю. Пока что у нас есть только один вариант в коммерческом предложении для пользователей, желающих обновить беспроводную сеть — Meraki.

Желаю удачи, но эта проблема длится уже больше года, так что не уверен, как быстро будет реальное решение. Поддержка очень важна для крупных корпоративных проектов. Исходя из этого, мы, скорее всего, никогда не предложим Ubiquiti для развёртываний в том масштабе, о котором вы говорите. Максимум — установка из 4 точек доступа. Для крупных проектов мне нужна поддержка уровня предприятия.

mmacpher1

Guest

#17

01.02.2020 05:15:00

Я тоже присоединяюсь к общему мнению... У нас средняя по размеру, в основном Unifi-среда, и у нас тоже проблемы с DHCP Timeout. Техподдержка, по идее, уже дважды «эскалировала» эту проблему, но никакой реакции нет. В прошлый раз мне сказали, что дело передано с «высоким приоритетом». Не понимаю, где ещё тикет с «высоким приоритетом» не получают ответа за 4 часа или меньше...

Наша сеть состоит из:
1x USG4p 4.4.44.5213871
1x USW 8POE 4.0.80.10875
1x USW 16POE 4.0.80.10875
1x USW PRO 24POE 4.0.80.10875
2x USW48POE 4.0.80.10875
2x UAPACMesh 4.0.80.10875
6x UAPACPro 4.0.80.10875
4x UAPBSXG 4.0.80.10875
4x UAPHD 4.0.80.10875

У меня больше 3000 сбоев DHCP/Timeout.

Сеть у нас сейчас максимально простая: только родной VLAN для корпоративного Wi-Fi и один VLAN для публичного Wi-Fi. Большинство ошибок происходит именно в VLAN. Публичный Wi-Fi открыт.

Я пробовал включать и выключать «Block LAN to WLAN Multicast and Broadcast Data» — разницы особой нет. Отключал DHCP Snooping, пытался отключать 5 ГГц — и это, по сути, все, что я смог сделать. Откатывать прошивку не могу.

Это очень важный клиент для моего бизнеса — судя по количеству оборудования выше и заказу еще на 10 коммутаторов среднего уровня.

DHCP — базовая сетевая услуга. Просто неприемлемо, что такая проблема вообще существует, не говоря уже о том, что, похоже, она тянется как минимум с выхода первых прошивок серии 4.x и контроллера 5.10.x...

Жаль, что я не нашёл эту тему раньше, чем давал своё согласие... Всё запустилось только вчера, и вы можете представить, насколько сейчас недоволен клиент.

Тикеты 2247715 и 2245446...

dmoseley

Guest

#18

27.01.2020 14:37:00

Не уверен, что моя проблема такая же, но у меня ВСЕГДА возникают таймауты DHCP-сервера в беспроводной сети Unifi. На всех SSID. Независимо от VLAN. Использую Windows DHCP-сервер. Проводная сеть работает без проблем. Но все в школе жалуются, потому что подключение к Wi-Fi — это лотерея. Так уже просто принято. Некоторые устройства могут не подключаться часами или днями, в то время как другие, прямо рядом, подключаются сразу. Свободных адресов достаточно. Я не сетевой инженер, но, вроде, всё настроено правильно и на DHCP-сервере, и на коммутаторах. Даже приглашал специалистов посмотреть. Но это древнее позорище для меня каждый день, и я очень хочу это исправить.

seanr22a

Guest

#19

25.01.2020 11:34:00

Возможно, это не связано напрямую, но в моём системном журнале много таких записей:
2020-01-25 12:29:20 Ошибка демона ubspanga dhcpd: hardware: необработанный пакет недоступен.

ubspanga — это USG 4, который работает как DHCP-сервер. Все три площадки (USG 4 на каждой) фиксируют эту ошибку.

Quick-Bit Guest	#20 22.01.2020 02:19:00 Похоже, я тоже наблюдаю нечто подобное. У меня есть компания с примерно 25 клиентами, которые каждый день настраивают около 10 новых планшетов на Windows для отправки. У меня есть SonicWall, который выступает DHCP-сервером, и я получаю жалобы, что беспроводные устройства подключаются к сети примерно за 20 минут. Я проверил одно из них — оно вообще не получил DHCP-информацию. Залез в логи SonicWall, но ничего не обнаружил. Собираюсь перезагрузить эту точку доступа и посмотреть, решит ли это проблему, потому что звучит очень похоже.

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