☰

Последовательное поведение, отмеченное у проблемных клиентов:

tag-icon • tag-icon dhcp
Последовательное поведение, отмеченное у проблемных клиентов:

Я был бы очень признателен за мысли и мнения по этой странной проблеме, с которой я столкнулся недавно.

Последовательное поведение, отмеченное у проблемных клиентов:

  • До определенного времени утром пользовательские ПК запрашивали использование адресов APIPA 169.254.x
  • Непринятие законных адресов, предлагаемых DHCP-сервером в течение этого периода времени
  • После второго DHCPDISCOVER по истечении указанного периода времени клиенты примут предлагаемый DHCP IP-адрес.

Краткое содержание

  • После выходных пострадала сеть одного здания
  • У пользователей, которые оставили свои машины включенными на выходные, проблем не возникло — обновления DHCP и т. д. работают нормально.
  • Пользователи, которые тщательно выключили свои ПК, однако столкнулись с проблемами DHCP после включения питания
  • Это повлияло на работу здания в течение двух часов, никаких неисправностей не обнаружено и они были устранены самостоятельно.
  • Сеть контролируется, проведено обширное расследование — за указанный период проблем с сетью не обнаружено.
  • DHCP-серверы выдают адреса по всему сайту, это было ограничено только одним зданием.
  • Клиентские машины в основном работают под управлением Windows 7, затронуты различные поставщики оборудования и сетевых карт — закономерности не обнаружены.
  • Смесь стационарных настольных компьютеров и ноутбуков
  • Проводное подключение
  • Затронута одна VLAN, хотя затронуты не все клиенты внутри VLAN.

Последовательность событий, зафиксированных в журнале DHCP-сервера

  1. DHCPDISCOVER — Клиентский ПК — Первое обнаружение действия клиентом
  2. DHCPOFFER DHCP-сервер — законный IP-адрес, предлагаемый DHCP-сервером
  3. DHCPREQUEST - Клиентский ПК - Запрос 169.254x от клиента: сообщение «неправильная сеть»
  4. DHCPNAK - DHCP Server - Сервер отрицательно подтверждает через NAK. Клиент должен начать процесс снова
  5. DHCPDISCOVER - Клиентский ПК - Второе действие обнаружения клиентом
  6. DHCPOFFER - DHCP-сервер - предлагается законный IP-адрес
  7. DHCPREQUEST - Клиентский ПК - Клиент запрашивает использование законного IP-адреса
  8. DHCPACK - DHCP-сервер - Сервер подтверждает положительно

Псевдообобщение пунктов RFC3927:

«Краткое» прочтение RFC 3927 «Динамическая конфигурация локальных адресов IPv4» — дает больше вопросов, чем ответов!

При использовании локальных адресов 169.254.x

  • 169.254./16 — локальная адресация, используемая, когда адреса или конфигурация адресов недоступны
  • Обычно запускается при запуске

Если хост использует адрес 169.254.x и маршрутизируемый адрес теперь доступен, хост должен

  • Использовать маршрутизируемый адрес
  • Прекратить рекламу 169.254.x

Методы маршрутизируемого адреса могут перестать быть доступными

  • Истечение срока аренды DHCP
  • Удаление адреса через ручную настройку
  • Перемещение хоста в новую сеть, где адрес больше не работает

Выбор адреса 169.254.x

  • Хосты Windows и MAC реализуют локальную автоматическую настройку ссылок
  • Примечание для Windows:
    • Как только обнаружено сетевое подключение, DHCPREQUEST или DHCPDISCOVER отправляется на интерфейс
    • Системы немедленно переходят в режим автоматической настройки, как только появляется возможность подключения
  • генерация псевдослучайных чисел, заданных на основе хоста, т.е. MAC
  • Происходит при загрузке

Заявление адреса 169.254.x

  • Хост должен проверить, не используется ли в сети локальный адрес ссылки 169.254.x.
  • Выполнено с помощью широковещательного ARP-запроса (включая целевой IP-адрес — подлежит проверке)

Объявление адреса 169.254.x

  • Вторая широковещательная рассылка ARP, но на этот раз включая IP-адреса отправителя и получателя, теперь выбраны IP-адреса 169.254.x

Окончательное резюме

  • Клиент DHCPDISCOVER и DHCP-сервер отвечает DHCPOFFER
  • Клиент должен принять это предложение маршрутизируемого адреса и прекратить использование локального адреса 169.254.x. По какой-то причине этого не происходит.
  • Последующий DHCPREQUEST от клиента выглядит как ARP-зонд или широковещательное объявление ARP? Что клиент использует 169.254.xx и может не коррелировать с ответами DHCP-сервера?
  • Вторая команда DHCPDISCOVER — неясно, что ее вызывает, так как изначально ПК были включены.

Спасибо за ваше терпение, если вы дочитали до этого места!

Буду очень признателен за помощь в понимании этого вопроса.

Спасибо,

решение1

У вас закончились адреса в пуле аренды? Может быть, поэтому он больше не может выдавать дополнительные IP-адреса.

Можете ли вы пинговать DHCP-сервер с затронутых машин, когда вы находитесь в Windows? Можете ли вы жестко закодировать NIC на неиспользуемый IP из диапазона DHCP, и вы получите доступ к сети для тестирования? Если необходимо, также протестируйте один из рабочих ПК на том же сетевом порту, что и нерабочая машина.

Связанный контент