Parameter Request List DHCP показывает запрос, а не готовые настройки
Фотография конкретного исполнения не приложена.
В диагностике иногда считают наличие option code в клиентском пакете доказательством полученной конфигурации. Но Parameter Request List перечисляет желаемые параметры. Между запросом и действующим состоянием узла остаются ответ сервера и обработка клиента.
RFC 2132 задаёт PRL как список option codes с возможным порядком предпочтений. Сервер должен стараться учитывать этот порядок, но ответ не обязан буквально повторять расположение. Отсутствие конкретного свойства требует анализа политики и доступного пространства сообщения.
Клиент способен использовать defaults или собственные локальные настройки для части параметров. Поэтому даже возвращённая option не всегда является единственным источником итогового состояния. Поддержка и правила приоритета конкретной ОС требуют отдельного подтверждения.
В приёмке сопоставляют PRL, полный DHCPACK и фактические параметры узла. Для обязательной option проверяют понятное поведение при её отсутствии. Отчёт должен показывать все три стадии. Один список запрошенных codes не подтверждает, что DNS, маршруты или другие значения действительно получены и используются приложениями клиента.
Основание — Numbered DHCPv4 base RFCs and selected lease, identity, option and reconfigure extensions, разделы RFC2132 9.8 Parameter Request List; RFC2131 3.5 Client parameters. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC DHCPv4 и дополнений. Поддержка options конкретными client, relay и server не проверялась. Это протокольный разбор и план приёмки, а не результат испытания оборудования; leases, адреса, маршруты и рабочая сеть не изменялись.
Запросы отправляются на наш e-mail из вашей почтовой программы.
