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

получен NAK от DHCP-сервера

получен NAK от DHCP-сервера, RouterOS

abbio90

Guest

08.06.2024 14:04:00

Всем привет! У меня есть routerboard, который работает как DHCP-клиент на Vodafone FWA-соединении. У меня настроен Vodafone ZTE CPE в режиме моста, на котором можно настроить только APN и VLAN, через который выставлен DHCP-клиент. Всё работает, RB получает динамический публичный IP с арендой на 30 минут. Странная штука в том, что каждые 15 минут я получаю NAK от DHCP-сервера и связь пропадает на 1-2 секунды. Потом всё снова работает с тем же IP. IP меняется только если перезагрузить CPE. В логах вижу такое сообщение: dhcp-client на vlan1038 потерял IP-адрес 1.2.3.209 — получил NAK от DHCP-сервера 1.2.3.210. От чего это может зависеть? Не думаю, что в DHCP-клиенте есть какие-то полезные настройки, которые могли бы это исправить.

spippan

Guest

29.01.2025 10:24:00

Та же проблема на сети 5G “3 AT” с ZTE MC801A в режиме моста: время от времени я получаю NAK со стороны WAN (ether1, который подключён к 5G-модему ZTE в режиме моста). 172.16.88.1 — локальный IP устройства ZTE (у моего MT на ether1-WAN также есть 172.16.88.2/26 для управления и доступа к webGUI). Время аренды 4 часа, даётся DHCP, но никогда не обнуляется. Я также видел сообщения NAK, когда вручную нажимал «обновить» в dhcp-client. Не понимаю, в чём причина, но когда это происходит, возникают короткие прерывания, которые раздражают.

mkx

Guest

29.01.2025 13:41:00

Совершенно нормально, что DHCP-клиент пытается обновить аренду DHCP после того, как истекает половина срока её действия. При этом клиент предлагает продлить аренду с тем же IP-адресом. Обычно DHCP-сервер подтверждает это (ACK), и всё продолжается ещё на половину срока аренды. Сервер DHCP может отвергнуть (NAK) “предложение” клиента — тогда клиент должен считать, что аренда аннулирована, и заново пройти процедуру получения новой аренды. В это время (несколько секунд) у клиента нет действующей аренды DHCP и, соответственно, IP-адреса. Что не нормально — это когда сервер DHCP отклоняет клиентское “предложение”, а после полной процедуры получения новой аренды всё равно выдаёт клиенту тот же IP-адрес. Единственное оправдание — если DHCP-ID клиента (который чаще всего напоминает MAC-адрес клиента) изменился с момента получения старой аренды, и сервер DHCP принимает его за совершенно нового клиента, пытающегося забрать чужую аренду. Если можешь, попробуй проверить состояние аренд на модеме ZTE… С другой стороны, меня бы не удивило, если у DHCP-сервера ZTE тоже есть свои косяки.

spippan

Guest

31.01.2025 09:48:00

спасибо @mkx, я знаю, как работает DHCP, и что обновление может происходить на половине максимального времени аренды. но здесь это не так. аренда действует 4 часа, но при этом NAK приходят задолго до окончания срока, например, когда остаётся ещё 2 часа. если происходит release или просто renew, обычно всё работает нормально. проблема ещё и в том, что это неконсистентно воспроизводится. к сожалению, я не контролирую DHCP-сервис на мостовом 5G модеме-роутере ZTE. интересно, можно ли фильтровать эти пакеты, если renew не инициируется с mikrotik.

mkx

Guest

31.01.2025 13:07:00

Про блокировку: так как DHCP обычно работает внутри L2 широковещательного домена, DHCP-рукопожатие не проходит через маршрутизаторы. А это значит, что любое DHCP-рукопожатие с шнурком ZTE обычно исходит от самого роутера, а не от каких-то устройств, подключённых к LAN-сегменту роутера. Если только у вас не все порты в режиме моста — тогда ZTE может услышать DHCP-запросы. Но в любом случае, скриншот логов уже доказывает, что DHCP-рукопожатие идёт именно от роутера к ZTE. Значит, особо с этим ничего не сделаешь. Можно попробовать прослушать DHCP-трафик на WAN-порту, чтобы увидеть, что именно обменивается между MT и ZTE, и проверить, не делает ли MT что-то неправильно. Но у меня нутром чувство, что виноват в неполадках именно ZTE.

spippan Guest	#6 0 01.02.2025 16:57:00 Это точно ZTE, который работает неправильно — WAN-порт не в мостовом режиме. Конечно, нет (; посмотрю, что можно с этим сделать. Сейчас я поменял режим моста на ZTE MC801A обратно на NAT, полностью отключил там DHCP и назначил статический IP. На WAN-порту MT стоит 172.16.88.2/26 с маршрутом по умолчанию "0.0.0.0/0 через 172.16.88.1". Пока работает, пока будет время разобраться (если только FTTH не появится в ближайшие дни, в чём я сильно сомневаюсь xD). Дополнительно я прописал 172.16.88.2 (MT) как DMZ-хост в настройках ZTE. Как и говорил, пока работает, но с условием двойного NAT (что меня особо не напрягает, ведь в этой конфигурации нет ничего связанного с VoIP/SIP). Больше не вижу NAK-ов таким образом, но, как всегда, спасибо всем за помощь и советы.

Читают тему

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