+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

DHCP-сервер постоянно назначает и снимает назначения.

DHCP-сервер постоянно назначает и снимает назначения., RouterOS

fotis3d

Guest

14.09.2022 08:52:00

Всем привет. Вдруг мой DHCP-сервер на HAP ac3 начал постоянно выдавать и тут же отзывать IP-адреса у Wi-Fi устройств. Есть идеи, в чем может быть проблема? Раньше такого не наблюдалось, но в последние дни это происходит постоянно. Использую HAP ac3 (главный роутер, версия v6.49.6) и HAP ac2 (в режиме точки доступа, в мосту, с LAN-подключением к первому, та же версия v6.49.6). Подключено около 60-65 Wi-Fi устройств. Буду очень признателен за любую помощь. Спасибо!

bpwl

Guest

01.12.2023 23:04:00

Привет! У меня такая же проблема с хотя бы одним устройством, подключённым к Wi-Fi. Устройства BYOD, поэтому у меня нет информации о клиентских устройствах и доступа к их настройкам. Настройка сделана на двух hAP ax3 с ROS 7.12, у каждого настроен DHCP-сервер на VLAN, обслуживающий одинаковые подсети, но с непересекающимися пулaми адресов (split scope). Клиенты должны закрепляться за одним DHCP-сервером для обновления аренды: если они получили адрес от одного сервера, другой не должен отказывать в нём (NACK) при отсутствии адреса в своём пуле. Но на деле клиент постоянно переключается между двумя DHCP-серверами.

Настройка одного из DHCP-серверов на hAP ax3 с опцией [Authoritative “after 10 seconds delay”] и удалением его списка аренды полностью остановила этот “флиппинг”. Теперь все аренды обслуживаются другим DHCP-сервером на втором ax3.

Интернет-статьи… исключения в MT??? IPAM 2020.2
ПРИЧИНА
Конфликт IP возникает из-за того, что оба DHCP-сервера управляют одинаковыми IP и выдают аренды на них. При правильно настроенном split scope два DHCP-сервера работают в одной подсети. После настройки каждый DHCP-сервер должен установить диапазон исключений, противоположный диапазону другого DHCP-сервера.

mkx

Guest

02.12.2023 15:12:00

Согласен с первой частью цитаты. Клиенты знают, какой DHCP-сервер выдал им аренду, поэтому могут попытаться обновить аренду через коммуникацию по unicast. Но, думаю, это не обязательное требование.

Однако со второй частью цитаты не согласен. Если DHCP-сервер считает себя авторитетным для определённой подсети, а клиент запрашивает адрес вне неё, сервер имеет право отклонить запрос (nack) и предложить аренду из собственного пула адресов.

Проблема в том, что у вас, похоже, три DHCP-сервера в одной и той же L2 broadcast-домене, но они не настроены на совместную работу. И эту часть сложно исправить. Как вы уже описали, можно запустить два (или три) DHCP-сервера MT в режиме активного/резервного, установив свойство authoritative на основном сервере в «yes», а на резервных — в «after-2sec-delay» или «after-10sec-delay». Тогда резервные серверы не будут мешать, если основной отвечает на запросы аренды. Но это не случай с разделённой зоной (split scope).

bpwl

Guest

02.12.2023 20:15:00

Ага, MKX, я как раз надеялся на твою реакцию. У меня на подсети (VLAN) всего два DHCP-сервера, и одно из устройств прыгало между ними. Серверы используют полнораздельный scope, но если они отвечают поочерёдно, клиент получает кучу NAK’ов и теряет wifi-соединение. (Не знаю, что было сначала: переподключения wifi или ошибки DHCP NAK.) После моей небольшой правки одно устройство снова взяло лизинг у DHCP-сервера с задержкой “after-10sec-delay”. Сейчас в сети почти нет нагрузки — всего 5 клиентов, а сервера подключены в одной точке. На форумах полно обсуждений про этот “DHCP deassign-assign”. Хотел сделать резервирование через VRRP (маршрутизация, SRCNAT, RADIUS (usermanager), DHCP и так далее), но пока далеко до того уровня, что был с кластером Fortigate или репликацией Windows AD.

mkx

Guest

03.12.2023 14:21:00

Думаю, что в типичном сценарии active/active лучше настроить все DHCP-серверы с одним и тем же пулом адресов. Тогда, когда клиент пытается обновить IP-адрес, любой из серверов его примет без проблем. Даже если предыдущую аренду выдавал другой DHCP-сервер, текущий, скорее всего, подтвердит этот адрес, потому что конфликтов с другими устройствами в сети, скорее всего, не будет. DHCP-серверы обычно подтверждают адреса, если они соответствуют настройкам, даже если сервер ещё не знает о DHCP-клиенте. Всё это работает нормально, пока нет DHCP-релеев и обязательные проверки доступности IP-адреса, которые выполняют сервер и клиент, не блокируются и не искажаются какими-то препятствиями на уровне L2.

bpwl

Guest

03.12.2023 15:20:00

Большое спасибо, @mkx. Я тоже думал сделать примерно то же самое на базе интерфейса VRRP. Но, честно говоря, зачем зависеть от VRRP? Я вообще никогда не видел проблем с DHCP-сервером, который не сохранял аренды на диск. Клиенты всё равно возвращались с тем же IP-адресом в аренде после перезагрузки DHCP-сервера. Видел скрипты, которые дублируют правила фаервола и аренды DHCP для сценариев мастер/резерв MT. Но мне нужно, чтобы только «статические» аренды были на обоих DHCP-серверах. Остальные могут получать любые адреса.

bpwl Guest	#7 0 07.12.2023 11:53:00 К сожалению… ничего не сработало, как ожидалось. Оба DHCP-сервера раздают конфликтующие IP-адреса из одного и того же пула (одинаковый IP разным устройствам). Один из DHCP-серверов авторитетный, другой — вообще никогда. Это не помогло. Wi-Fi устройства часто оффлайн. Когда оба сервера онлайн, конфликт можно обнаружить. Кстати, переключатель снятия/назначения IP-адреса снова в деле.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры