Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Передача трафика не ретранслируется беспроводными точками доступа, из-за чего возникают сбои DHCP., UniFi Network
 
Привет! Кратко: у меня проблема с некоторыми точками доступа UAP-AC-PRO на прошивке 4.3.13.11253 — они неправильно передают широковещательный трафик. Периодически у клиентов возникают проблемы с получением IP через DHCP. Это происходит, как правило, с клиентами, которые давно не были в сети или подключаются впервые. Проблема, вроде как, проходит сама по себе, но когда именно — непредсказуемо. Все попытки воспроизвести баг по команде провалились, но нам всё же удалось захватить PCAP для клиента, у которого проблема проявлялась в реальном времени. Захваты трафика делались одновременно на проводной стороне eth0, на беспроводной ath6 интерфейсе точки доступа и на самом клиенте через Wireshark.

Вот что я понял из PCAP: клиент шлёт DHCP Discover, сервер отвечает DHCP Offer. Этот DHCP Offer приходит на проводной интерфейс точки доступа, передаётся по ath6, но клиент его так и не получает. DHCP сервер (Palo Alto Networks PA-220) в этой сети использует широковещательную рассылку для DHCP Offer — понимаю, что это не лучший вариант, но сейчас исправить это я не могу. Исходя из этого, я точно исключаю проблемы со свитчами — пакеты до UAP-AC-PRO доходят однозначно, а клиент их не получает!

Что я уже пробовал:
- Выключил лишние точки доступа (их было слишком много).
- Улучшил планирование каналов, чтобы избежать перекрытия и помех между точками.
- Увеличил значение DTIM с 1 до 3.
- Перезапустил фаервол PAN-220.
- Создал новый сайт в UniFi Controller (версия 5.12.72 на Linux) и перевёл туда все устройства.

У меня открыт тикет в Ubiquiti (2455306, а также чаты 2456386 и 2457194). Они передали дело в команду эскалации, но посоветовали написать и сюда.
 
Привет, у меня такая же проблема с IPv4. У меня PA220 с прошивкой 9.0.10 и интерфейсом trunk в слое 2. Я настроил два подинтерфейса с разными VLAN (201 и 202), а нативный интерфейс в слое 2 (VLAN 9) используется для управления. Этот интерфейс подключён к коммутатору Cisco через trunk Ethernet с тегами VLAN 201 (wifi для сотрудников) и VLAN 202 (wifi для гостей), а VLAN 9 без тега (управление).

Если я на том же коммутаторе ставлю один порт в access-режим для VLAN 201 и другой — для VLAN 202, то устройства, подключённые к этим портам, работают нормально (DHCP, пинг, интернет, интранет и так далее). Но если я подключаю WiFi-AP с двумя SSID на VLAN 201 тег и VLAN 202 тег на том же коммутаторе, настроенном в режиме trunk (untag VLAN 9, tag VLAN 201 и VLAN 202), и подключаю по WiFi какое-то устройство (iPhone, планшет, ПК и т.п.) к любому из SSID (VLAN 201 или VLAN 202), запрос DHCP не работает. Если же указать статический IP на беспроводных устройствах, они работают нормально.

У меня есть запись этих подключений, и я вижу, что от WiFi-устройства идёт цикл DHCP, а PaloAlto сбрасывает эти пакеты, потому что они дублируются. В этом разделе сообщества я вижу такую же проблему, как у меня. Кто-нибудь её решил? У меня точка доступа Ubiquiti с версией 4.4, а в прошивке Ubiquiti версии 5.43.16.12479 есть UnGi Routing & Switching. Может, эта версия решит мою проблему? Спасибо.
 
Конечно, но это всего лишь временное решение.
 
@Greelan, не можешь ли ты просто сократить интервал перезаключения?
 
Могу подтвердить, что проблема с IPv6 RA / GTK, упомянутая в этой ветке, до сих пор актуальна на версии 4.3.20 на AC-PRO. Устройства не получают IPv6-адреса, пока не пройдет интервал обновления ключа GTK после подключения. Проводные клиенты получают адреса мгновенно. Разочаровывает, ведь я обновился с 4.0.80 в надежде, что это починят.
 
Часть моего вопроса касалась MAC-адреса — некоторые новые мобильные устройства меняют свой MAC-адрес для probe-запросов и, возможно, для широковещательных передач. Я знаю, что подобные проблемы уже возникали раньше. Я бы посмотрел DORA-пакеты одного устройства, сравнил исходные и целевые MAC-адреса: правильные ли они, можно ли определить, какой MAC-адрес принадлежит какому устройству? Появляется ли у пакетов, исходящих с Windows DHCP-сервера, правильная метка после DISCOVER-пакета? Думаю, что поскольку вы используете helper address, ваш Windows DHCP-сервер не работает на транке, а находится в одном access VLAN. Поэтому пакеты, выходящие для ненативного VLAN, должны быть тегированы самим Windows-сервером, чтобы коммутатор мог отправить их на нужные порты в соответствующем VLAN.
 
IP-хелпер настроен на SonicWall. Это позволяет пересылать DHCP-запросы, помеченные для другой VLAN, на наш Windows-сервер. Пока у Windows-сервера есть область (scope) в той же подсети, что и VLAN, он ответит и выдаст IP-адрес из этой области.
 
В исходном DHCP широковещательном сообщении от одного из неработающих устройств Android или Apple, вы можете сравнить MAC-адрес этого широковещания с фактическим MAC-адресом устройства? Вы указали IP Helper адрес в настройках сети, чтобы DHCP широковещания перенаправлялись на нужный IP-адрес сети? Или у вашего DHCP-сервера есть интерфейс в каждой локальной сети?
Страницы: 1
Читают тему (гостей: 1)