
Я пытаюсь использовать существующий dhcpd
для автоматической настройки сетевых PDU Raritan. Это работает примерно как загрузка PXE: есть дополнительные параметры DHCP, которые указывают устройству извлекать файл конфигурации через TFTP. Однако для этого используются параметры DHCP поставщика.
Я определил пространство опций и новый класс для PDU. Я вижу, что мой класс сопоставляется (я установил DNS и доменное имя по-разному внутри класса, и эти опции отправляются). Однако опции, специфичные для поставщика, не отправляются (проверено с помощью dhcpdump
). У сервера нет проблем с конфигурацией (которая в любом случае регистрируется).
Что может быть причиной отсутствия отправки вариантов поставщика?
set vendor-string = option vendor-class-identifier;
option space RARITAN code width 1 length width 1 hash size 3;
option RARITAN.pdu-tftp-server code 1 = ip-address;
option RARITAN.pdu-update-control-file code 2 = text;
option RARITAN.pdu-update-magic code 3 = text;
class "PDUs" {
match if option vendor-class-identifier = "Raritan PDU 1.0";
vendor-option-space RARITAN;
option vendor-class-identifier "Raritan PDU 1.0";
option domain-name-servers 1.1.1.1;
option domain-name "pdu.net";
option RARITAN.pdu-tftp-server 10.251.0.9;
option RARITAN.pdu-update-control-file "raritan-update.cfg";
option RARITAN.pdu-update-magic "20180822-0005";
}
Ни в одной из существующих областей не используется vendor-option-space
, поэтому я не думаю, что здесь есть какие-либо конфликты.
решение1
Вам следует проверить 2 вещи:
- ваш клиент Raritan отправляет опцию 43 (опция, специфичная для поставщика) в DHCPREQUEST, и
- вы не взламываете опцию 43 в своей конфигурации где-либо еще.
Я столкнулся с той же проблемой и через несколько часов нашел в своей огромной базе данных dhcpcd.conf
с тысячами клиентов строку option cisco-wlc-encap code 43 = encapsulate cisco-wlc
, которая отбрасывала все другие попытки задать параметр 43 с помощью синтаксиса class и vendor-option-space.