@ Карта сайта News Автора!

Bog BOS: Протокол BOOTP/DHCP

Последние изменения:
2025.01.24: sysadmin: rsyslog (статья и пример центрального коллектора переработаны)
2024.11.22: sysadmin: systemd-journald (централизованное хранение)

Последнее изменение файла: 2024.11.18
Скопировано с www.bog.pp.ru: 2025.05.20

Bog BOS: Протокол BOOTP/DHCP

BOOTP (Bootstrap Protocol) как и RARP обеспечивает с помощью специального сервера выделение IP адреса клиенту по его MAC адресу (например, при загрузке устройства, не имеющего возможности хранить свой собственный IP адрес), а также позволяет клиентам узнавать другие параметры загрузки (например, имя программы, загружаемой затем с помощью TFTP) и использует UDP в качестве протокола канального уровня. Это позволяет использовать маршрутизаторы (bootp relay) для передачи запросов и ответов из одного сегмента локальной сети в другой. Протокол DHCP (Dynamic Host Configuration Protocol) является надстройкой над BOOTP (для совместимости с bootp relay) и позволяет серверу выделять IP адреса клиентам динамически на ограниченный срок.

Протокол BOOTP

Порт сервера - UDP/67 (BOOTPS), клиента - UDP/68 (BOOTPC). Клиент делает широковещательный (255.255.255.255 - всем в локальной сети, номера которой я не знаю - и ff:ff:ff:ff:ff:ff) запрос bootrequest (один нефрагментированный пакет): обязательно содержит аппаратный MAC адрес клиента и может содержать преполагаемый IP-адрес клиента, имя сервера и обобщенное имя файла для загрузки. Сервер отвечает пакетом bootreply (обычно unicast, т.к. MAC и IP адреса клиента ему известны): IP-адрес клиента, обобщенное имя файла замещается на полное имя файла исходя из конфигурации сервера, типа и адреса клиента и др. Собственно загрузка файла осуществляется клиентом с помощью протокола TFTP. Клиент должен быть в состоянии ответить на ARP запросы, чтобы мог работать TFTP-сервер.

Формат пакетов (в скобках упомянуты тэги /etc/bootptab и /etc/dhcpd.conf):

Формат дополнительной информации (RFC 2132, опции): первые 4 байта имеют значение 99.130.83.99, что позволяет определить ее наличие (может быть использовано другое согласованное значение, определяющее собственный формат этого поля). Далее расположен список элементов (имена и тексты в NVT ASCII). Каждый элемент имеет однобайтовую этикетку, описывающую его тип. Типы 0 и 255 состоят только из этикетки (0 - заполнитель, 255 - конец данных). Остальные типы элементов вторым байтом имеют длину элемента. Если для опции требуется более 255 байт, то можно использовать несколько раз - порядок конкатенации определяется RFC-3396. Стандартизованные типы (в скобках упомянуты тэги /etc/bootptab и опции /etc/dhcpd.conf):

  1. маска подсети (sm, subnet-mask)
  2. смещение времени относительно UTC (в секундах, time-offset; предпочтительно указание часового пояса TZ - опции 100 и 101)
  3. список IP адресов маршрутизаторов (первый - предпочтительный, gw, routers)
  4. список IP адресов серверов времени (RFC 868, не NTP!; time-servers)
  5. список IP адресов серверов имен (IEN 116, не DNS!) (ien116-name-servers)
  6. список IP адресов DNS серверов (domain-name-servers)
  7. список IP адресов серверов syslog (lg, log-servers)
  8. список IP адресов серверов "Quote of the Day" (RFC 865)
  9. список IP адресов серверов печати (LPR/LPD, RFC 1179, lpr-servers)
  10. список IP адресов серверов Imagen Impress (impress-servers)
  11. список IP адресов серверов поиска ресурсов (RLP, RFC 887)
  12. доменное имя хоста клиента, возможно (обязательно?) только локальная часть (hn, host-name)
  13. число блоков в загрузочном файле (по 512 байт, до 64k, bs, boot-size)
  14. имя сервера и имя файла для coredump (Merit)
  15. имя домена клиента (domain-name)
  16. IP адрес swap сервера (swap-server)
  17. путь монтирования диска root
  18. имя файла (берется затем клиентом с помощью TFTP) с продолжением дополнительной информации (extensions-path)
  19. должен ли клиент передавать пакеты с интерфейса на интерфейс, т.е. работать маршрутизатором (forwarding, ip-forwarding)
  20. разрешать ли source routing чужих IP пакетов (non-local-source-routing)
  21. фильтры для source routing (policy-filter)
  22. максимальный размер датаграммы для сборки клиентом (не менее 576) (max-dgram-reassembly)
  23. TTL для исходящих от клиента датаграмм (default-ip-ttl)
  24. время ожидания для алгоритма автораскрытия MTU (RFC 1191, path-mtu-aging-timeout)
  25. таблица значений MTU для алгоритма автораскрытия MTU (RFC 1191)
  26. MTU интерфейса (не менее 68, interface-mtu)
  27. все ли локально подключенные подсети имеют одинаковый MTU (all-subnets-local)
  28. широковещательный IP адрес локальной подсети (broadcast-address)
  29. использовать ли ICMP для автораскрытия маски подсети (perform-mask-discovery)
  30. отвечать ли на ICMP запросы автораскрытия маски подсети (mask-supplier)
  31. использовать ли механизм поиска маршрутизаторов (RFC 1256, router-discovery)
  32. IP адрес сервера механизма поиска маршрутизаторов (RFC 1256, router-solicitation-address)
  33. список статических маршрутов в виде списка пар: сеть (нельзя задавать 0.0.0.0), адрес маршрутизатора (без маски, т.к. это классовая маршрутизация, для нормальной смотри опцию 121; static-routes)
  34. согласовать ли использование "хвостов" в канальных кадрах (RFC 893, trailer-encapsulation)
  35. время жизни элементов ARP кеша (секунд, arp-cache-timeout)
  36. версия Ethernet: version 2 (RFC 894) или IEEE 802.3 (RFC 1042) (ieee802-3-encapsulation)
  37. TTL для исходящих от клиента TCP пакетов (default-tcp-ttl)
  38. интервал посылки сообщений TCP keepalive (tcp-keepalive-interval)
  39. посылать ли TCP keepalive c мусором для совместимости со старыми реализациями (tcp-keepalive-garbage)
  40. имя домена NIS (nis-domain)
  41. список IP адресов серверов NIS (nis-servers)
  42. список IP адресов серверов NTP (ntp-servers)
  43. информация в формате изготовителя оборудования (например, PXE), формат определяется опцией 60 (vendor class)
  44. список адресов серверов имен NetBIOS over TCP/IP (RFC 1001, RFC 1002, netbios-name-servers)
  45. список адресов серверов NBDD NetBIOS over TCP/IP (RFC 1001, RFC 1002, netbios-dd-server)
  46. тип узла NetBIOS over TCP/IP (RFC 1001, RFC 1002, netbios-node-type)
  47. область NetBIOS over TCP/IP (RFC 1001, RFC 1002, netbios-scope)
  48. список IP адресов серверов шрифтов X Window System (font-servers)
  49. список IP адресов менеджеров дисплея (xdm) X Window System (x-display-manager)
  50. требуемый клиенту IP адрес (DHCPDISCOVER) (dhcp-requested-address )
  51. запрашиваемое (DHCPDISCOVER, DHCPREQUEST) или предоставленное (DHCPOFFER) время аренды IP адреса в секундах относительно момента запроса (dhcp-lease-time)
  52. использовать ли поля имени сервера и имени загрузочного файла для передачи дополнительных опций (DHCP, dhcp-option-overload)
  53. тип сообщения DHCP (см. описание протокола; dhcp-message-type)
    1. DHCPDISCOVER
    2. DHCPOFFER
    3. DHCPREQUEST
    4. DHCPDECLINE
    5. DHCPACK
    6. DHCPNAK
    7. DHCPRELEASE
    8. DHCPINFORM
    9. DHCPFORCERENEW - сервер переводит клиента в состояние RENEW (RFC-3203, RFC-6704)
    10. DHCPLEASEQUERY - запрос информации от сервера (RFC-4388)
    11. DHCPLEASEUNASSIGNED - запрос информации от сервера (RFC-4388)
    12. DHCPLEASEUNKNOWN - запрос информации от сервера (RFC-4388)
    13. DHCPLEASEACTIVE - запрос информации от сервера (RFC-4388)
    14. DHCPBULKLEASEQUERY - запрос информации от сервера (RFC-6926)
    15. DHCPLEASEQUERYDONE - запрос информации от сервера (RFC-6926)
    16. DHCPACTIVELEASEQUERY - запрос информации от сервера (RFC-7724)
    17. DHCPLEASEQUERYSTATUS - запрос информации от сервера (RFC-7724)
    18. DHCPTLS - запрос информации от сервера (RFC-7724)
  54. идентификатор сервера DHCP (IP адрес), указывается сервером в DHCPOFFER, чтобы клиент мог различить предложения от различных серверов (возможно также указание в DHCPACK и DHCPNAK); указывается клиентом в DHCPREQUEST, чтобы показать, какое предложение он принял (dhcp-server-identifier)
  55. список кодов опций, значения которых клиент хочет узнать от сервера (dhcp-parameter-request-list)
  56. текст сообщения об ошибке (DHCPNAK, DHCPDECLINE) (dhcp-message)
  57. максимальный размер сообщения DHCP, которое клиент готов принять (DHCPDISCOVER, DHCPREQUEST) (dhcp-max-message-size)
  58. T1 - интервал времени (в секундах), через который клиент DHCP должен перейти в режим запроса подтверждения на право владения IP адресом (RENEWING), по умолчанию - 0.5 от срока аренды (dhcp-renewal-time)
  59. T2 - интервал времени (в секундах), через который клиент DHCP должен перейти в режим получения нового IP адреса (REBINDING), по умолчанию - 0.875 от срока аренды (dhcp-rebinding-time)
  60. используется DHCP клиентом для указания варианта конфигурации (vendor class), сервер возвращает информацию только в формате изготовителя оборудования (например, PXEClient в PXE) опция 43
  61. уникальный в подсети идентификатор клиента DHCP (например, MAC адрес или полное доменное имя), в протоколе BOOTP для идентификации клиента использовался его MAC адрес, UUID в PXE; dhcp-client-identifier)
  62. имя домена NIS+ (nisplus-domain)
  63. список IP адресов серверов NIS+ (nisplus-servers)
  64. имя TFTP сервера, если поле имени сервера использовано под дополнительные опции (DHCP)
  65. имя загрузочного файла, если поле имени загрузочного файла использовано под дополнительные опции (DHCP; bootfile-name)
  66. список IP адресов Mobile IP Home Agent
  67. список IP адресов серверов SMTP (smtp-server)
  68. список IP адресов серверов POP3 (pop-server)
  69. список IP адресов серверов NNTP (nntp-server)
  70. список IP адресов серверов WWW (www-server)
  71. список IP адресов серверов finger (finger-server)
  72. список IP адресов серверов IRC (irc-server)
  73. список IP адресов серверов StreetTalk
  74. список IP адресов серверов StreetTalk Directory Assistance
  75. cписок типов пользователя (user class, задаётся клиентом для выбора сервером одной из конфигураций параметров) - RFC-3004
  76. FQDN имя сообщаемое клиентом и кто отвечает за обновление DNS записей A и PTR, сервер отвечает флагами (DDNS, RFC-4702 - PTR всегда обновляется сервером)
  77. Option 82: информация о клиенте вставляетсся посредником (relay agent) при перехвате широковещательных запросов, если giaddr равен 0 - RFC-3046 (основная причина - мы не доверяем клиенту, а нижнему посреднику? а если при вставке будет превышен MTU? IPSEC?), сервер в ответе посреднику возвращает её, посредник вырезает её перед пересылкой ответа клиенту; содержит от 1 до 255 подопций:
    1. Circuit ID - интерфейс, порт или канал, к которому подключён клиент (agent.circuit-id)
    2. Remote ID - уникальный идентификатор клиента (agent.remote-id)
    3. Link Selection (RFC-3527) - IP адрес подсети клиента, позволяет разделить giaddr на адрес обращения к посреднику и адрес сети клиента (для случая без посредника см. опция 118) (agent.link-selection)
    4. Subscriber-ID (RFC-3993) - идентифицирует подписчика (в чём отличие от клиента?) независимо от физического подключения
    5. RADIUS (RFC-4014) - позволяет передать аттрибуты, полученные посредником от RADIUS сервера - User-Name, Service-Type, Vendor-Specific, Session-Timeout, Framed-Pool, Framed-IPv6-Pool
    6. аутентификация информации посредника (RFC-4030) - дополнение к средствам аутентификации клиента (RFC-3118)
    7. информация изготовителя (RFC-4243) - централизованные IANA идентификаторы предприятия и привязанные к ним значения
    8. флаги посредника (RFC-5010) - позволяет посреднику сообщить серверу был ли запрос от клиента широковещательным
    9. переопределение идентификатора сервера (RFC-5107) - позволяет посреднику сообщить серверу значение поля опции 54 (Server Identifier) для вставки в его ответ, чтобы клиент посылал последующие нешироковещательные сообщения также через посредника
    10. идентификатор агента (RFC-6925) - позволяет посреднику указать свой уникальный для административного домена идентификатор (Relay-ID)
    11. исходящий порт посредника (RFC-8357) - позволяет указать следующему в цепочке, что ответ надо посылать на используемый в пакете порт
    12. DHCPv4/DHCPv6 Virtual Subnet Selection (VPN) (RFC-3046 и RFC-6607)
    13. VSS Control (RFC-3046 и RFC-6607)
  78. список IP адресов серверов iSNS (Internet Storage Name Service) - iSCSI и iFCP - RFC-4174
  79. аутентификация (общий секрет, HMAC-MD5, RFC-3118)
  80. системная архитектура клиента PXE (RFC-4578, pxe-system-type)
  81. версия универсального сетевого интерфейса PXE (UNDI) (RFC-4578, pxe-interface-id?)
  82. LDAP (резервирован в RFC-3679, но не описан)
  83. универсальный идентификатор клиента PXE (UUID) (RFC-4578, pxe-client-id)
  84. PCode (описание часового пояса по IEEE 1003.1, например "EST5EDT4,M3.2.0/02:00,M11.1.0/02:00", RFC-4833, pcode)
  85. TCode (описание часового пояса по базе TZ, например, "Europe/Moscow", RFC-4833, tcode)
  86. запрет автоконфигурации клиента (RFC-2563)
  87. приоритет типов сервисов имён (DNS, NIS, NetBIOS, NIS+, локальный /etc/hosts) - RFC-2937
  88. выбор клиентом (вероятно посредником, требуется giaddr) желаемой подсети указанием IP адреса подсети - RFC-3011 (subnet-selection)
  89. список поиска доменов DNS (search в /etc/resolv.conf) - RFC-3397 (domain-search)
  90. статические маршруты (в отличие от опции 33 для бесклассовой маршрутизации) в виде пар цель (адрес подсети и ширина маски), IP адрес маршрутизатора (0.0.0.0 для сети на том же линке) - RFC-3442
  91. Vendor Class в формате, позволяющем несколько независимых поставщиков, что не позволяет опция 43 и 60 - RFC-3925
  92. информация в формате поставщика в формате, позволяющем несколько независимых поставщиков, что не позволяет опция 43 и 61 - RFC-3925
  93. PXE в формате поставщика, формат и содержание определяется используемым NBP (RFC-4578), пересекается с Etherboot signature, сервером авторизации DOCSIS и TFTP сервер для IP Phone
  94. PXE в формате поставщика, формат и содержание определяется используемым NBP (RFC-4578), пересекается, формат и содержание определяется используемым NBP с опции ядра, IP адрес сервера звонков
  95. PXE в формате поставщика, формат и содержание определяется используемым NBP (RFC-4578), пересекается с ?
  96. PXE в формате поставщика, формат и содержание определяется используемым NBP (RFC-4578), пересекается с удалённый сервер статистики
  97. PXE в формате поставщика, формат и содержание определяется используемым NBP (RFC-4578), пересекается, формат и содержание определяется используемым NBP с IEEE 802.1Q VLAN ID
  98. PXE в формате поставщика (RFC-4578), пересекается, формат и содержание определяется используемым NBP с IEEE 802.1D/p Layer 2 Priority
  99. PXE в формате поставщика (RFC-4578), пересекается, формат и содержание определяется используемым NBP с Diffserv Code Point (DSCP)
  100. PXE в формате поставщика, формат и содержание определяется используемым NBP (RFC-4578), пересекается с HTTP прокси для телефонии
  101. настройки агента Session Initiation Protocol (SIP) - RFC-6011
  102. настройки SZTP (Secure Zero Touch Provisioning (SZTP) - настройка пришедшего с фабрики сетевого устройства - RFC-8572
  103. инициализация аутентификации для последуюещего FORCERENEW
  104. выбор сервера DNS для узлов с несколькими интерфейсами (RDNSS Selection), позволяет задать приоритет, уровень доверия и обслуживаемые домены и сети для первичного и запасного сервера DNS - RFC-6731; каждый интерфейс получает свой набор от своего DHCP сервера
  105. аналог опции 66 но без использования DNS и sname но позволяет несколько IP - адрес сервера TFTP - RFC-5859 (tftp-server-address); пересекается с Etherboot и имя файла с настройками GRUB; ранее назывался VoIP Configuration Server Address
  106. -157 массовый запрос информации о лизинге (RFC-6926)
  107. IP адреса серверов Port Control Protocol (PCP) (RFC-7291)
  108. выделение клиентам разделяемых IP адресов - 1 адрес на всех, каждый клиент обслуживает свой набор портов(RFC-7618)
  109. Manufacturer Usage Description (MUD) позволяет клиену сообщить о типе доступа и требуемой сетевой функциональности - настройка прав доступа, опции DHCP позволяют передавать URL (HTTP/HTTPS), по URL находится описание в формате модулей YANG (JSON), дополнительно описывается LLDP и расширение сертификата X.509 (RFC-8520, IoT)
  110. Etherboot - не оформлено
  111. IP телефония - не оформлено
  112. Etherboot, пересекается с PacketCable и CableHome - не оформлено
  113. RFC 5071 - PXE - pxelinux.magic (F1:00:74:7E) (RFC-4578)
  114. RFC 5071 - PXE - имя файла конфигурации pxelinux.configfile (RFC-4578) (loader-configfile)
  115. RFC 5071 - PXE - префикс файла pxelinux.pathprefix (RFC-4578) (loader-pathprefix)
  116. RFC 5071 - PXE - время перезагрузки в секундах pxelinux.reboottime (RFC-4578) (loader-reboottime)
  117. IPv6 Rapid Deployment on IPv4 Infrastructures (RFC-5969)
  118. метод поиска Local Location Information Server (LIS), выдаётся доменное имя, из которого формируется URI (NAPTR, U-NAPTR, HELD) (RFC-5986)
  119. позволяет клиенту динамически запросить подсеть, также позволяет организовать иерархию серверов DHCP (RFC-6656)
  120. информация вставляется посредником (relay) о клиенте; DHCPv4/DHCPv6 Virtual Subnet Selection (VPN) (RFC-6607)
  121. -254 (ранее с 128 - было много пересечений, потом с 192) - 254: зарезервированы для локального использования (RFC-3942) (Tномер, option option-номер)

Средств обеспечения безопасности нет, в ответ клиент может получить фальшивый пакет, а сервер DDoS на исчерпание пространства IP адресов. Поэтому на периферии сети порты UDP/67 и UDP/68 (а лучше все ненужные пакеты) должны быть заблокированы сетевым экраном, а на сервере BOOTP должны быть проделаны дырки для входящих пакетов в ipchains или iptables (привожу формат /etc/sysconfig/{ipchains,iptables}): 

-A input -s 0.0.0.0/0.0.0.0 68:68 -d 0.0.0.0/0.0.0.0 67:67 -p udp -j ACCEPT

-A INPUT -i имя-интерфейса -m state --state NEW -p udp --sport 68 --dport 67 -j ACCEPT

Аналогичные дырки надо проделать для исходящих пакетов сервера и пакетов, пересылаемых DHCP посредником.

Если в ядре включена фильтрация поддельных IP-адресов (martian address filtering), то на DHCP сервере её придется отключить (по крайней мере для адресов 0.0.0.0 и 255.255.255.255), а также, возможно, отключить запись в журнал (0 в /proc/sys/net/ipv4/conf/*/log_martians).

Экран можно усилить, заменив "универсальные" 0.0.0.0/0.0.0.0 на адреса ваших клиентов/сервера, но учитывайте, что исходящими IP адресами клиентов могут быть также 0.0.0.0, а входным - 255.255.255.255.

Протокол DHCP

Протокол DHCP использует тот же самый формат пакетов и те же UDP порты для обмена сообщениями между серверами и клиентами. Это позволяет DHCP серверу обслуживать BOOTP клиентов и использовать исторически сложившуюся инфраструктуру BOOTP посредников. DHCP не определяет политику назначения IP адресов и прочих параметров, а лишь обеспечивает механизм её реализации. Адрес может выделяться на ограниченный срок (выражается в секундах относительно момента запроса) или навсегда. DHCP позволяет свести настройку сетевых параметров клиентов к минимуму. В сети может быть установлено несколько серверов. Сервер должен хранить выделенные параметры при перезагрузках клиентов и сервера, чтобы по возможности выделять один и тот же адрес. При запросах клиент может идентифицироваться не только своим MAC адресом, но и специальной опцией "уникальный идентификатор клиента" (UUID или GUID). Аналогично сервер указывает свой IP адрес в опции "идентификатор сервера". Пакеты от клиента DHCP (тип bootrequest) могут быть следующих видов (задаётся опцией "тип сообщения DHCP"):

Ответные пакеты от сервера DHCP (тип bootreply) могут быть следующих видов (задаётся опцией "тип сообщения DHCP"):

В протоколе предусмотрена возможность перевода клиента в режим обновления IP адреса (DHCPFORCERENEW) и опроса БД сервера DHCP о выданных адресах (DHCPLEASE*, DHCPBULKLEASEQUERY, DHCPLEASEQUERYDONE, DHCPACTIVELEASEQUERY, DHCPLEASEQUERYSTATUS, DHCPTLS).

Посредник (dhcp relay) получив широковещательный запрос DHCPDISCOVER передаёт его серверу (или следующему посреднику в цепочке) не меняя, кроме заполнения поля giaddr (только первый в цепочке) и вставки опции 82. В giaddr вставляется адрес интерфейса, получившего запрос от клиента. В TTL записывается 255 (?). Агент проверяет лимит шагов (hop) и увеличивает счётчик шагов на 1. При общении с сервером агент не использует широковещательную передачу. Ответ сервера передаётся клиенту. Агент использует giaddr для выбора интерфейса при пересылке ответа сервера клиенту. Широковещательность ответа определяется флагом в сообщении.

dhcping - средство тестирования сервера DHCP (рекомендуется осторожность!).

dhtest - эмулятор множества клиентов для тестирования DHCP сервера.

Сервера BOOTP

Пакет bootp-2.4.3-7.i386.rpm (Red Hat Linux 5.2). Содержит программы bootpd и bootptest. Конфигурационный файл - /etc/bootptab (см. bootptab(8)): 

printer0:\
  :ht=ether:ha=ethernet-адрес:\
  :hn:vm=rfc1048:sm=маска-сети:ip=адрес-принтера:\
  :lg=адрес-syslog-сервера:\
  :sa=адрес-TFTP-сервера:\
  :T144="имя-TFTP-файла-с-параметрами-принтера":

Устанавливался и на более поздние версии Red Hat Linux, только надо создать файл /etc/xinetd.d (не забыть презапустить xinetd: "/etc/rc.d/init.d/xinetd reload") 

service bootps
{
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/bootpd
        server_args             = -i -d4 -t 1 /etc/bootptab
        disable                 = no
}

Сервер bootpd от HP в комплекте программ для JetDirect. Тестовая программа bootpquery делает запрос и выводит ответ BOOTP сервера. В качестве параметров можно указать MAC адрес клиента (если не совпадает с настоящим, то сервер д.б. возвращать широковещательный ответ) и имя сервера (ключ -s). Конфигурационный файл - /etc/bootptab (см. bootptab(8)): 

printer0:\
  :ht=ether:ha=ethernet-адрес:\
  :hn:vm=rfc1048:sm=маска-сети:ip=адрес-принтера:\
  :lg=адрес-syslog-сервера:\
  :sa=адрес-TFTP-сервера:\
  :T144="имя-TFTP-файла-с-параметров-принтера":

rpc.bootparamd в Solaris использует данные из /etc/bootparams, реализует специфическую для Sun RPC версию сервера, обеспечивающего дополнительные параметры для загрузки. Скрипт /etc/init.d/nfs.server (AKA /etc/rc3.d/S15nfs.server) запускает "/usr/sbin/rpc.bootparamd", если существует директория /tftproot. Если у вас нет бездисковых станций Sun, то он вам не нужен.

Сервер bootparamd в Red Hat Linux поставляется в виде пакета bootparamd-0.17-7 (RH 7.2) и реализует ту же самую специфическую для Sun RPC версию сервера, обеспечивающего дополнительные параметры для загрузки.

Столкнулся с забавной "плюшкой" firmware JetDirect: все IP-адреса в списке дополнительных элементов должны быть выровнены на границу слова, поэтому строки переменной длины (имена хостов и файлов) должны быть в конце списка, либо иметь четную длину. bootpd из поставки JetDirect знает об этом, а для dhcpd и стандартного bootpd пришлось менять имена хостов.

Сервер ISC DHCP

Пакет dhcp-2.0pl5-8 (RH 7.2) или dhcp-3.0pl1-15 (RH 8.0) или dhcp-3.0.1-11 (FC3) или dhcp-3.0.5-33.el5_9 (CentOS5.11) или dhcp-4.1.1-63.P1.el6.centos (CentOS 6.10) или dhcp-4.2.5-83 (CentOS 7.9) или dhcp-server-4.3.6-49.el8 (RockyLinux 8.8) или dhcp-server-4.4.2-18.b1.el9 (RockyLinux 9.2) содержит BOOTP/DHCP сервер dhcpd и посредник dhcrelay от ISC (имеются также пакеты dhclient и dhcp-devel - dhcp-common, dhcp-libs, dhcpd-pools). Поддерживается работа DHCP клиента, сервера и посредника. Обеспечивается динамическое изменение DNS.

Перед выдачей динамического адреса клиенту запись об этом заносится в конец специального файла (dhcpd.leases(5), /var/lib/dhcp/dhcpd.leases) для страховки, т.е. правильным является последнее значение. Чтобы размер файла не вырос до бесконечности время от времени создаётся новый файл, старый переименовывается в dhcpd.leases~. Файл содержит записи аренды, объявления хостов, групп и подгрупп в формате dhcpd.conf (объявления хостов, групп и подгрупп для объектов, динамически созданных с помощью OMAPI, см. ниже). Каждая запись аренды содержит выделенный IP-адрес, время начала и конца аренды в человеколюбивом формате (но в UTC), тип оборудования и MAC адрес, идентификатор клиента, host-name, abandoned (адрес нельзя было выдавать), текущее и следующее состояния аренды, agent.circuit-id и agent.remote-id (см. описание опций).

В версии 3.0 убрана поддержка неизвестных серверу опций в виде "option-144", теперь их необходимо описывать явно.

Журнал записывается на syslog, источник - DAEMON.

Процедура запуска для init.d в файле /etc/rc.d/init.d/dhcpd (start, stop, restart, status). Параметры командной строки хранятся в файле /etc/sysconfig/dhcpd. Для обеспечения запуска при загрузке надо выполнить 

chkconfig --level 2345 dhcpd on

Процедура запуска для systemctl описывается сервисами dhcpd, dhcpd6 и dhcrelay (выключены по умолчанию). Добавляются группа и пользователь dhcpd (/, /sbin/nologin), запуск производится от имени пользователя dhcpd. Файл /etc/sysconfig/dhcpd содержит инструкцию как поменять ключи запуска ("-f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid"). Скрипт /etc/NetworkManager/dispatcher.d/12-dhcpd обеспечивает перезапуск сервиса при включении интерфейса. dhcpd требует сети и синхронизации времени (фальшивый сервис /usr/lib/systemd/system/time-sync.target - см. systemd.special(7)).

После запуска номер процесса сохраняется в файле/var/run/dhcpd.pid (--no-pid?).

После изменения конфигурационного файла /etc/dhcpd.conf (/etc/dhcp/dhcpd.conf или /etc/dhcp/dhcpd6.conf) (описание - dhcpd.conf(5), dhcp-options(5), dhcp-eval(5) удалён) необходимо перезапустить сервер.

Каталог /etc/dhcp/scripts содержит скрипты, которые запускаются от имени dhcpd (/etc/dhcp/scripts/README.scripts содержит инструкцию по настройке прав доступа).

Файл /etc/openldap/schema/dhcp.schema содержит схему LDAP (?).

Параметры запуска /usr/sbin/dhcpd (DHCPv4 и DHCPv6 взаимоисключающие):

Протокол OMAPI позволяет подсоединяться к серверу по TCP/7911 (с аутентификацией, TSIG, криптографическая подпись с использованием разделяемого секрета), чтобы проверить его состояние или изменить конфигурацию или содержимое БД (просмотр, создание, удаление, просмотр и изменение атрибутов для объектов типа аренда, хост, группа, управление). Имеется командная оболочка omshell(1). Пример генерации ключа: "dnssec-keygen -a HMAC-SHA256 -T KEY -b 256 -n HOST omapi_key" ("dnssec-keygen -a HMAC-MD5 -b 512 -n HOST omapi") (выводит префикс имён файлов приватного - имя.private - и публичного - имя.key - ключей?). Вставить его в dhcpd.conf (ограничить права доступа!): 

omapi-port 7911;
key omapi {
#        algorithm HMAC-SHA256; не заработал
        algorithm HMAC-MD5;
        secret "содержимое приватного ключа";
};
omapi-key omapi;

Для использования OMAPI необходимо создать локальный объект нужного типа, заполнить некоторые поля и совместить локальный объект с удалённым. Для объекта аренды ищет только по IP адресу и только из пула. Например, чтение состояния аренды: 

omshell
# server localhost
# port 7911
# key-algorithm { HMAC-MD5 | HMAC-SHA1 |  HMAC-SHA224 |  HMAC-SHA256 | HMAC-SHA384 |  HMAC-SHA512 }
key omapi "содержимое-приватного-ключа"
connect
new lease # создать локальный объект
set ip-address = адрес # частично заполнить
open # совместить с удалённым
refresh
close # нет в документации

Типы объектов:

Развитие и поддержка сервера ISC DHCP прекращены в 2022 году на версии 4.4.3 в пользу их нового сервера Kea. При этом в RHEL8 остаётся ISC DHCP версии 4.3.6, а в RHEL9 - версии 4.4.2, а Kea отсутствует.

dhcpd-pools - анализ использования пулов адресов от ISC.

dhcpcd - минимальный сервер DHCP и rdisc.

Отличия версий

Настройка сервера DHCP ISC

Конфигурационный файл имеет свободный текстовый формат. Комментарии начинаются со знака '#' и продолжаются до конца строки, но не внутри кавычек. Регистр ключевых слов значения не имеет. Файл состоит из утверждений двух типов: параметры и объявления. Объявления описывают топологию сети и группируют параметры. Объявления могут быть вложенными. Параметры и простые объявления завершаются точкой с запятой. Определяющие вложенную область действия объявления заключают её в фигурные скобки и не имеют завершающей точки с запятой. Параметры внутри объявления д.б. описаны до вложенных объявлений.

Для каждой подсети, к которой подключён DHCP сервер, должно быть объявление подсети subnet (даже если он её не обслуживает). Если подсети подключены к одному интерфейсу, то объявления этих подсетей д.б. помещены внутрь объявления shared-network. Кстати, с помощью посредника (bootp relay) через интерфейс могут быть видны сегменты, не подключённые непосредственно.

Если адреса клиентам внутри подсети должны выделяться динамически, то необходимо объявить пул адресов внутри подсети pool (все пулы на одном интерфейсе - общие, невозможно определить к какой подсети на разделяемом интерфейсе принадлежит клиент). При описании интервала адресов (range) вне пула создаётся виртуальный объемлющий пул без параметров.

Для клиентов со статическими адресами необходимо поместить объявление host внутрь объявления подсети. Если требуется загружать клиента в различных подсетях, то для него можно описать несколько объявлений host (если ему необходимо назначить различные параметры в зависимости от подсети) или несколько параметров fixed-address в одном объявлении.

Объявления различного типа с одинаковыми параметрами можно группировать внутри объявления group.

Клиенты с динамически выделяемыми адресами могут быть сгруппированы согласно объявлению классов class (класс клиента определяется в момент запроса в соответствии с передаваемыми им опциями - например, идентификатором клиента). Имеется также грязный хак по распределению клиентов по подклассам исключительно с целью оптимизации времени работы сервера. Возможно объявление класса (spawning class), автоматически порождающего подклассы в зависимости от значения получаемого от клиента параметра.

Имеются условные операторы.

Перед объявлениями самого верхнего уровня могут быть указаны глобальные параметры.

Поиск параметров для клиента происходит в следующей последовательности (приоритет имеет более конкретная область действия):

  1. объявление host (по идентификатору клиента или MAC адресу; сначала просматриваются те, которые содержат фиксированный IP адрес, подходящий для подсети клиента, затем не содержащие фиксированных адресов; объявление host глобально даже внутри subnet и shared-network)
  2. объявление class
  3. объявление pool (по IP адресу)
  4. объявление subnet (по IP адресу)
  5. объявление shared-network (по IP адресу)

Синтаксис: 

shared-network "имя" {
  [ параметры ]
  [ объявления ]
}

subnet IP-адрес-сети netmask маска {
  [ параметры ]
  [ объявления ]
}

pool {
  range [ dynamic-bootp ] начальный-IP-адрес [ конечный-IP-адрес ];
  # флаг dynamic-bootp разрешает выделение адреса из пула bootp клиентам
}

host имя-хоста { # имя используется при идентификации клиента, если он посылает dhcp-client-identifier
  [ hardware адрес] # используется при идентификации клиента
  [ параметры ]
  [ объявления ]
}

group {
  [ параметры ]
  [ объявления ]
}

class "имя-класса" {
  [ match ... ]
  [ spawn with option имя-опции ]
  [ lease limit максимальное-число-клиентов-в-классе ]
  [ параметры ]
}

subclass "имя-класса" константа;

subclass "имя-класса" константа {
  [ параметры ]
}

if условие {
  [ параметры ]
} [ elsif условие {
      [ параметры ]
} ]
 ...
  [ else {
      [ параметры ]
} ]

log (приоритет, выражение)

Для управления доступом в любой области объявления могут быть использованы утверждения allow, deny или ignore (аналогично deny, но без записи сообщения в журнал), указаны значения по умолчанию:

Для управления выделением адресов из пула внутри объявления пула могут быть использованы утверждения allow и deny со следующими параметрами (они обрабатываются до выделения адреса):

Параметры (там, где возможно, приведены значения по умолчанию):

Опции протокола DHCP: option имя значение; (флаг: on/off или true/false; устаревшие опции и всякие странные сервисы не упоминаю; DHCPv6 не описываю; значения опций используются как при создании ответов сервера, так и извлекаются из запросов клиентов при вычислении выражений, условий и поиске класса; смысл опций описан выше; вместо IP адреса можно указать DNS имя, разрешаемое в 1 IP адрес при первом запросе после старта dhcpd; текст в NVT ASCII необходимо заключать в кавычки; строку октетов (байт) в NVT ASCII необходимо заключать в кавычки или представлять как разделяемые двоеточием октеты в виде 2 шестнадцатеричных цифр; доменное имя не должно заключаться в кавычки; имена доменов в списке доменов заключаются в кавычки и разделяются запятыи)

Можно самостоятельно описывать опции, не реализованные сервером dhcpd (допускается использовать номера, зарезервированные для локального использования - границы интервала номеров опций для локального использования сдвигались дважды: от 128 к 192 к 224) в виде: option имя code номер = определение-структуры. Определение структуры может быть следующим (нельзя описать последовательность структур):

Описанную опцию можно использовать по имени, например: 

# описание опции
option jetdirect144 code 144 = text;
# использование
option jetdirect144 "имя-TFTP-файла-с-параметрами-принтера";

Описание и использование своего пространство опций для vendor-encapsulated-options делается в следующей последовательности:

  1. определение пространства (количество байт на код опции для DHCPv4 - 1, количество байт на длину строки для DHCPv4 обычно 1, длина 0 - ?): option space имя-пространства-опций [ [ code width число ] [ length width число ] [ hash size число ] ];
  2. описание подопции: option имя-пространства-опций.имя-опции code номер = определение-структуры;
  3. указание на использование пространства для vendor-encapsulated-options: vendor-option-space имя-пространства;
  4. задание значения: option имя-пространства-опций.имя-опции значение;

Например: 

option space PXE;
option PXE.prompt code 10 = {unsigned integer 8, text};
...
shared-network "имя" {
  if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
    vendor-option-space PXE;
    option PXE.prompt 10 "Select Boot Server (F8)";
    ...
  }
}

Условие в операторе if/elsif в зависимости от значения опций в запросе задаётся в виде булевского выражения (null в любой части выражения приводит к результату null для всего выражения, что имеет значение false)

Значение параметра может задаваться в виде выражения (записывается как "имя-параметра = выражение"). Выражения также используются для условных описаний параметров. Реализованы следующие типы выражений:

log (приоритет, выражение) вызывает выдачу на syslog.

execute (программа [, параметр, ... ]); вызывает синхронное выполнение внешней программы с позиционными параметрами. Неперчатные символы преобразуются в "\nnn".

Сервер поддерживает протокол восстановления (failover, draft-ietf-dhc-failover-07.txt) - два DHCP сервера разделяют общий пул динамически распределяемых адресов и подменяют друг друга в случае падения. Протокол не стандартизован (и недодуман) до конца - чувствуйте себя бета-тестерами, если хотите. Описание опускаю.

Сервер поддерживает (описание опускаю) протокол динамического обновления DNS, используя следующие алгоритмы (задаётся параметром ddns-update-style - требуется указать хотя бы none, иначе сервер не запустится; TSIG и DNSSEC не реализованы):

Возможно назначить выполнение блока операторов при наступлении одного из типов событий: выделение адреса (commit), освобождение (release), истечение времени аренды (expiry).

Настройка ISC DHCP сервера для обслуживания PXE клиентов.

Конфигурация может быть запрошена из LDAP в соответствиис draft-ietf-dhc-ldap-schema-01.txt. Параметры настройки: ldap-server, ldap-port, ldap-username, ldap-password, ldap-base-dn, ldap-method, ldap-debug-file, ldap-ssl, ldap-tls-reqcert, ldap-tls-ca-file, ldap-tls-ca-dir, ldap-tls-cert, ldap-tls-key, ldap-tls-crlcheck, ldap-tls-ciphers, ldap-tls-randfile. Не пробовал.

Кроме сервера протокола DHCP обеспечивает сервер протокола BOOTP, поэтому имеет множество параметров настройки, но для каждого клиента BOOTP достаточно иметь секцию host в /etc/dhcp/dhcpd.conf (subnet, естественно, общий для всей подсети), например, обеспечение загрузки сетевого принтера HP JetDirect для dhcp-2.0: 

subnet ip-адрес-подсети netmask маска-подсети {
  host имя-принтера {
    hardware ethernet MAC-адрес;
    fixed-address IP-адрес;
    always-reply-rfc1048 on;
    next-server TFTP-сервер;
    option subnet-mask маска-подсети;
    option host-name "имя-принтера";
    option log-servers имя-сервера-syslog;
    option option-144 "имя-TFTP-файла-с-параметрами-принтера";
  }
}

Сервер DHCP Huawei Cloud Engine

DHCP сервер коммутатора Huawei Cloud Engine.

Посредник DHCP

Посредник dhcrelay(8) из комплекта ISC DHCP транслирует запросы клиентов и ответы серверов между сегментами сети (конфигурационного файла нет), не использовал:

DHCP relay коммутатора Huawei Cloud Engine.

Клиенты DHCP

Пакет dhclient-3.0.5-33.el5_9 (RHEL5) содержит клиент протокола DHCP от ISC. Конфигурационный файл - /etc/dhclient.conf (dhclient.conf(5). При обновлении (REBIND, RENEW) использует не широковещательный запрос, а непосредственный IP адрес сервера, выдавшего IP адрес. При описании интерфейса с BOOTPROTO=dhcp скрипт /etc/sysconfig/network-scripts/ifup-eth вызывает клиента dhclient для обслуживаемого интерфейса ("[-1] -q -cf /etc/dhclient-${DEVICE}.conf -lf /var/lib/dhclient/dhclient-${DEVICE}.leases -pf /var/run/dhclient-${DEVICE}.pid"). При этом создаются дополнения к настройке клиента /etc/dhclient-ИмяИнтерфейса.conf вида "send host-name "имя хоста""). Журнал работы выводится на syslog (local7).

Список арендованных адресов дописывается в конец файла аренды - /var/lib/dhcp/dhclient.leases (dhclient.leases(5)), файл читается при запуске клиента (используется если сервер DHCP недоступен при загрузке или его нет), временами обрезается. Также описание аренды берётся из директивы lease в dhclient.conf.

Ключи запуска dhclient:

Переменные окружения (перебиваются ключами): PATH_DHCLIENT_CONF, PATH_DHCLIENT_DB (аренда), PATH_DHCLIENT_PID, PATH_DHCLIENT_SCRIPT.

Конфигурационный файл - /etc/dhclient.conf (dhclient.conf(5). Синтаксис файла конфигурации такой же, как и у файла конфигурации сервера. В RHEL/CentOS/... не используется, т.к. для управления интерфейсами используются внешние средства (/etc/sysconfig, NetworkManager) и /etc/sysconfig/network-scripts/ifup-eth запускает dhclient с использованием свежесозданного /etc/dhclient-${DEVICE}.conf (достаточно удалить DHCP_HOSTNAME?). Параметры и объявления:

Скрипт dhclient-script вызывается dhclient для установки интерфейса до выдачи запроса серверу, при проверке предложенного адреса, для полной установки интерфейса, при проверке предустановленой аренды при отсутствии сервера и при полном отсутствии информации об адресе. Скрипт для RHEL6/CentOS/... правит /etc/resolv.conf (/etc/resolv.conf.predhclient), /etc/localtime (/etc/localtime.predhclient, DHCP_TIME_OFFSET_SETS_TIMEZONE), /etc/ntp.conf (/etc/ntp.conf.predhclient), определяет маршруты (ip route), адреса (ip addr), настраивает интерфейсы (ifconfig - адрес, маска, широковещательный адрес, MTU), устанавливает hostname, domainname (NIS, /etc/yp.conf и /etc/yp.conf.predhclient). Скрипт проверяет наличие пользовательских расширений /etc/dhclient-enter-hooks (определяет функцию make_resolv_conf), /etc/dhclient-${interface}-down-hooks, /etc/dhclient-down-hooks, и /etc/dhclient-exit-hooks (модифицирует код возврата). При вызове передаётся переменная окружения reason, определяющая состояние процесса:

Если DHCP сервер раздаёт адреса NTP серверов, то на сервере NTP необходимо добавить в /etc/sysconfig/network строку PEERNTP=no, иначе dhclient будет "улучшать" /etc/ntp.conf.

Для управления клиентом можно использовать тот же OMAPI протокол, что и для управления сервером: приостановка работы, возобновление работы с переконфигурацией всех интерфейсов, завершение работы.

RHEL6/CentOS6 добавляет

RHEL7/CentOS7 добавляет

NetworkManager запускает для обслуживаемого интерфейса (/usr/libexec/nm-dhcp-helper - это не скрипт, а исполняемый файл без описания): /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-bond0.pid -lf /var/lib/NetworkManager/dhclient-УИД-интерфейс.lease -cf /var/lib/NetworkManager/dhclient-интерфейс.conf интерфейс

Необходимо учесть, что клиент DHCP должен обрабатывать пакеты, когда сеть ещё не сконфигурирована! Нет IP адреса, пакеты проходят мимо фильтров и т.д. - подробности.

Microsoft Windows 2000 Server запрашивает (идентификатор клиента - его MAC адрес; vendor class identifier - "MSFT 5.0"):

Microsoft Windows XP не требует широковещательного ответа (не уверен до конца, т.к. у меня проходит через посредника), имеет случайный номер транзакции, Vendor Class (опция 60) - "MSFT 5.0", передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), имя хоста (не имеет отношения к DNS, простое имя, заданное при установке, опция 12), FQDN имя сообщаемое клиентом и кто отвечает за обновление DNS записей A и PTR (простое имя, заданное при установке, опция 81), информация в формате изготовителя (43), разрешение автоматической конфигурации (116), запрашивает:

Microsoft Windows 7 Pro не требует широковещательного ответа (не уверен до конца, т.к. у меня проходит через посредника), имеет случайный номер транзакции, Vendor Class (опция 60) - "MSFT 5.0", передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), имя хоста (не имеет отношения к DNS, простое имя, заданное при установке, опция 12), идентификатор DHCP сервера при наличии (54), FQDN имя сообщаемое клиентом и кто отвечает за обновление DNS записей A и PTR (простое имя, заданное при установке, опция 81, только REQUEST?), запрашивает:

Microsoft Windows 10 и 11 не требует широковещательного ответа (не уверен до конца, т.к. у меня проходит через посредника), имеет случайный номер транзакции, Vendor Class (опция 60) - "MSFT 5.0", передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), имя хоста (не имеет отношения к DNS, простое имя, заданное при установке, опция 12), идентификатор DHCP сервера при наличии (54), FQDN имя сообщаемое клиентом и кто отвечает за обновление DNS записей A и PTR (простое имя, заданное при установке, опция 81, только REQUEST?), запрашивает:

Клиент Megarac Aviator фирмы American Megatrends (платформа Intel SR1680MVR и H2000JF - Pilot ServerEngines LLC Pilot III) не требует широковещательного ответа, повторный запрос идёт широковещательно, имеет случайный номер транзакции, Vendor Class (опция 60) - "udhcp 0.9.9-pre7" и запрашивает (применяет только первый раз после включения питания):

Клиент ServerEngines LLC Pilot II (платформа Intel SR1600UR и SR2600UR) не требует широковещательного ответа, передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), имеет случайный номер транзакции, Vendor Class (опция 60) - "udhcp 0.9.9-pre" и запрашивает:

Клиент ServerEngines LLC Pilot III (платформа Intel H2000JF и R2208GZ4GC) не требует широковещательного ответа, передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), имя хоста (не всегда, не DNS, "DCMIмакадрес", 12), имеет случайный номер транзакции, Vendor Class (опция 60) - "udhcp 0.9.9-pre" (иногда "DCMIмакадрес", а иногда "-D") и запрашивает:

Клиент Nuvoton BMC (системная плата Supermicro X9DRD) не требует широковещательного ответа, имеет случайный номер транзакции, Vendor Class (опция 60) - "udhcp 1.12.0", передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61) и запрашивает :

Клиент Emulex Pilot III (Integrated BMC, iBMC) (платформа Intel H2000G) не требует широковещательного ответа, имеет случайный номер транзакции, Vendor Class (опция 60) - "udhcp 1.20.2", передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), максимальный размер сообщения - 576 (57), имя хоста (не имя DNS, а строку "DCMI" и MAC адрес первого интерфейса системной платы), и запрашивает :

Клиент ASPEED AST2400 BMC (системная плата Supermicro X10DRD) не требует широковещательного ответа, имеет случайный номер транзакции, Vendor Class (опция 60) - "udhcp 1.23.1", передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), максимальный размер сообщения - 576 (57) и запрашивает :

Клиент Aspeed AST2500 (платформы Intel H2000P и R2000WF) не требует широковещательного ответа, имеет случайный номер транзакции, Vendor Class (опция 60) - "udhcp 1.33.1", передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), максимальный размер сообщения - 576 (57), имя хоста (краткое), и запрашивает :

Клиент AST2600 BMC (платформа Supermicro 640P-E1CR36L) не требует широковещательного ответа, имеет случайный номер транзакции, Vendor Class (опция 60) - "udhcp 1.32.1", в DISCOVER? передаёт максимальный размер сообщения 1260 (576? опция 57) , передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61) и запрашивает:

Клиент iLO2 не требует широковещательного ответа, имеет случайный номер транзакции, Vendor Class (60) - "CPQRIB3" (Compaq вечно живой!), передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), максимальный размер сообщения - 576 (57), имя хоста ("ILOсерийный"), максимальный размер сообщения 576 (опция 57), требуемое время аренды 1 день (51) и запрашивает :

Protium RPP не требует широковещательного ответа, имеет случайный номер транзакции, передаёт Host Name (не DNS, серийный номер?), передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), Vendor Class - "udhcp 1.7.0", запрашивает:

Принтер Kyocera TASKalfa 1801 не требует широковещательного ответа, имеет случайный номер транзакции, передаёт Host Name (не DNS, серийный номер?), передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), FQDN имя сообщаемое клиентом и кто отвечает за обновление DNS записей A и PTR (простое имя, заданное при установке, опция 81), Vendor Class отсутствует, запрашивает:

Принтер Epson GT-S55 не требует широковещательного ответа, имеет случайный номер транзакции, передаёт Host Name (не DNS), передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), Vendor Class - "udhcp 0.9.8", запрашивает:

Принтер Canon imageRUNNER2202n (imageRUNNER2204n) не требует широковещательного ответа, имеет случайный номер транзакции (imageRUNNER2204n - последовательный), передаёт максимальный размер сообщения - 1430 (57), желаемое время аренды - 8 часов (51), Vendor Class отсутствует, запрашивает:

Принтер Canon imageRUNNER2520 не требует широковещательного ответа, обновления аренды не умеет - каждый цикл запросов начинает с DISCOVERY, имеет последовательный номер транзакции (0x00000002), передаёт имя хоста (полное доменное имя), желаемый IP адрес (50), уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), идентификатор сервера (54), Vendor Class отсутствует, запрашивает:

Принтер Canon imageRUNNER2630 хочет широковещательного ответа, обновления аренды не умеет - каждый цикл запросов начинает с DISCOVERY, имеет случайный номер транзакции, передаёт максимальный размер сообщения - 1500 (57), имя хоста (полное доменное имя), желаемый IP адрес (50), уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), идентификатор сервера (54), Vendor Class - "Canon iR2630", запрашивает:

Принтер HP LaserJet 5200dtn (Q7543A, JetDirect J7934G) не требует широковещательного ответа, имеет случайный номер транзакции, передаёт Host Name (не DNS, "NPIмакадрес"), передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), FQDN имя сообщаемое клиентом и кто отвечает за обновление DNS записей A и PTR (простое имя, заданное при установке, опция 81), максимальный размер сообщения DHCP - 576 (57), желаемое время аренды 1 день (51), Vendor Class - "Hewlett-Packard JetDirect",запрашивает:

Принтер HP Color LasetJet MFP 179fnw не требует широковещательного ответа, имеет случайный номер транзакции, передаёт Host Name (не DNS, "HPмакадрес"), передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), Vendor Class - "HP Network Printer",запрашивает:

Принтер HP Color LaserJet Pro MFP M281fdw (M283fdw, M402dn) не требует широковещательного ответа, имеет постоянный (0x201e0000? 0x4b520000? 0xbefa0000?) номер транзакции, передаёт Host Name (простое имя), передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), FQDN имя сообщаемое клиентом и кто отвечает за обновление DNS записей A и PTR (простое имя, заданное при установке, опция 81), максимальный размер датаграммы - 65535 (22), максимальный размер сообщения DHCP - 4096 (57), Vendor Class - "HP LaserJet" ("HP LaserJet", "Hewlett-Packard LaserJet"), User Class (77) содержит "DMfg=HP;Typ=Printer;Mod=HP Color LaserJet MFP M281fdw;Ser=серийный-номер" (неправильнофоормленный в случае M402dn), запрашивает:

Принтер HP LaserJet Pro 400 MFP M425dn (CF288A) (HP LaserJet Pro 400 MFP M425dw (CF288A)) не требует широковещательного ответа, имеет постоянный (0x50da0000? 0x25ba0000?) номер транзакции, передаёт Host Name (простое имя), передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), FQDN имя сообщаемое клиентом и кто отвечает за обновление DNS записей A и PTR (простое имя, заданное при установке, опция 81), максимальный размер датаграммы - 65535 (22), максимальный размер сообщения DHCP - 4096 (57), Vendor Class - "Mfg=Hewlett Packard;Typ=Printer;Mod=;Ser=...;" ("Mfg=Hewlett Packard;Typ=Printer;Mod=HP LaserJet 400 MFP M425dw;Ser=...;") ; запрашивает:

ИБП со встроенным сетевым управлением APC Back-UPS HS 500 не требует широковещательного ответа, имеет постоянный номер транзакции (0x12233456), Vendor Class отсутствует, не может забыть старый DHCP сервер запрашивает:

Сетевая карта управления ИБП AP9617 A10/AP9619 (NMC ex, поколение 1) (а также АВР APC AP7724/AP7721) передаёт неправильно сформатированный с точки зрения wireshark пакет (User Class - "SUMX..." или "ATS...", 77), не требует широковещательного ответа, имеет последовательный номер транзакции, передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), Vendor Class - APC, запрашивает:

Сетевая карта управления ИБП AP9630/AP9631 (NMC поколение 2) передаёт неправильно сформатированный с точки зрения wireshark пакет (User Class - "SUMX...", 77, поправлено?), не требует широковещательного ответа, имеет последовательный номер транзакции, передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), имя хоста (не DNS - "apc" и 6 последних цифр MAC адреса; можно поменять; 12); FQDN имя сообщаемое клиентом и кто отвечает за обновление DNS записей A и PTR (простое имя, заданное при установке, опция 81), Vendor Class - APC, запрашивает:

Сетевая карта управления ИБП NetMan 204 не требует широковещательного ответа, имеет случайный номер транзакции, передаёт имя хоста (не DNS - "netman" и 8 последних цифр MAC адреса или назначенное администратором; 12), запрашивает:

Сетевая карта управления Stulz C7000IOC не требует широковещательного ответа, имеет постоянный номер транзакции, ничего о себе не передаёт, запрашивает:

Коммутатор KVM Aten CN8000 не требует широковещательного ответа, имеет случайный номер транзакции, при DISCOVERY и первом REQUEST просит бесконечную аренду, маску, шлюз и серверы DNS; при последующих DHCPREQUEST ничего не посылает кроме старого адреса и ничего не просит.

Коммутатор HP V1910G (в девичестве 3COM Baseline Switch 2900) не требует широковещательного ответа, имеет случайный номер транзакции, имя хоста (простое имя DNS, 12), передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), максимальный размер сообщения - 1152 (57), Vendor Class - "HPE. HPE 1910-24-PoE+ (190W) Switch", запрашивает:

Коммутатор D-Link DGS-1510-52X не требует широковещательного ответа, имеет постоянный номер транзакции (0xc904c904), передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), Vendor Class - "D-Link CorporationDGS-1510-52X", запрашивает:

SAN HP MSA P2000 G3 не требует широковещательного ответа, имеет случайный номер транзакции, имя хоста (не DNS - "HP-StorageWorks-MSA-Storage-...", 12), передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), Vendor Class - "udhcp 1.13.3", запрашивает:

Клиент RHEL/CentOS 5 не требует широковещательного ответа, передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), передаёт Host Name (это не DNS), имеет случайный номер транзакции, Vendor Class отсутствует, запрашивает:

Клиент RHEL/CentOS 6 не требует широковещательного ответа, передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), имеет случайный номер транзакции, передаёт Host Name (краткий, или нет?), Vendor Class отсутствует (или такой - "anaconda-Linux 2.6.32-220.el6.x86_64 x86_64" или "anaconda-Linux 2.6.32-358.el6.x86_64 x86_64"), запрашивает:

Клиент RHEL/CentOS 7 не требует широковещательного ответа, передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61; иногда неизвестный тип DUID - 4), имеет случайный номер транзакции, Vendor Class отсутствует, запрашивает:

Клиент Fedora 21 (?) не требует широковещательного ответа, передаёт уникальный в подсети идентификатор клиента DHCP (MAC адрес и время, 61), имеет случайный номер транзакции, передаёт Host Name (не DNS, 12), максимальный размер сообщения - 1500 (57), Vendor Class - "dhcpcd-6.0.5:Linux-5.0.21:x86_64:GenuineIntel"), запрашивает:

Клиент Debian не требует широковещательного ответа, имеет случайный номер транзакции, передаёт Host Name (не имеет отношения к DNS), уникальный в подсети идентификатор клиента DHCP (MAC адрес или MAC адрес и время 61), Vendor Class отсутствует, запрашивает:

Клиент Ubunta 20.04 (и прочие ?) не требует широковещательного ответа, имеет случайный номер транзакции, передаёт Host Name (не всегда, не имеет отношения к DNS), уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), максимальный размер сообщения - 65535 (57, не во всех версиях Ubunta?), Vendor Class отсутствует, запрашивает:

Клиент Linux Mint (?) не требует широковещательного ответа, имеет случайный номер транзакции, передаёт Host Name (не имеет отношения к DNS), уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), максимальный размер сообщения - 65535 (57), Vendor Class отсутствует, запрашивает:

Клиент PXE BIOS платформы Intel R2000GZ и платформы SuperMicro X9DRi-F и платформы Intel SR2625URLX (встроен в сетевую карту Intel?) в DISCOVER передаёт максимальный размер сообщения 1260 (опция 57), UUID клиента PXE (опция 97, RFC-4578), системная архитектура клиента 0 (IA x86 PC) (опция 93, RFC-4578), UNDI (Network Device Interface) клиента PXE версии 2.1 (опция 94, RFC-4578), идентификатор класса поставщика (Vendor class identifier, опция 60): "PXEClient:Arch:00000:UNDI:002001", номер транзакции - последние 4 байта MAC адреса клиента, запрашивает очень много (DHCPOFFER и DHCPACK посылается сервером трижды):

Клиент PXE UEFI сетевой карты LR-Link PCIe x8 40G LREC9902BF-2QSFP+ (Intel XL710-Q2) в DISCOVER передаёт максимальный размер сообщения 1472 для DISCOVERY и 65280 для REQUEST(опция 57), UUID клиента PXE (опция 97, RFC-4578), UNDI (Network Device Interface) клиента PXE версии 3.16 (опция 94, RFC-4578), системная архитектура клиента 7 (EFI BC) (опция 93, RFC-4578), идентификатор класса поставщика (Vendor class identifier, опция 60): "PXEClient:Arch:00007:UNDI:003016", случайный номер транзакции, запрашивает очень много):

Клиент PXE Virtual Box передаёт максимальный размер сообщения 1472 (опция 57), UUID клиента PXE (опция 97, RFC-4578), системная архитектура клиента 0 (IA x86 PC) (опция 93, RFC-4578), UNDI (Network Device Interface) клиента PXE версии 2.1 (опция 94, RFC-4578), идентификатор класса поставщика (Vendor class identifier, опция 60): "PXEClient:Arch:00000:UNDI:002001", случайный номер транзакции, информация о классе пользователя (опция 77): "iPXE7..." (wireshark считает неправильно оформленным), уникальный в подсети идентификатор клиента DHCP (MAC адрес, 61), Etherboot (опция 175) - что это?, запрашивает

Ссылки
@ Карта сайта News Автора!

Bog BOS: Протокол BOOTP/DHCP

Последние изменения:
2025.01.24: sysadmin: rsyslog (статья и пример центрального коллектора переработаны)
2024.11.22: sysadmin: systemd-journald (централизованное хранение)
Copyright © 1996-2025 Sergey E. Bogomolov; www.bog.pp.ru