Комментарии 6
Отличный троллейбус из буханки хлеба вышел. Плюсую!
А вы, кстати, не натыкались на такое, что Mellanox Coneect-X с undionly не хочет грузиться? Точнее, не может DHCPREQUEST пакет отправить после загрузки? (DHCPDISCOVER отправляет и ответ получает)
С конкретной моделью не работал, но в общем нахватался забавных ситуаций. Не готов ответить по-научному и со всеми пруфами, но направление для отладки, надеюсь, смогу вам подсказать.
В общем случае могу сказать, что если вы уверены, что DHCPOFFER доходит до сетевухи, а сетевуха не хочет отправлять DHCPREQUEST, то это значит, что ваш оффер не удовлетворяет требованиям сетевухи.
Я, в частности, обнаружил, что «обычный» PXE игнорирует офферы, если в них нет next-server и bootfile. В некоторых случаях у сетевухи два режима загрузки — в соответствии со спецификацией интела и какой-то «обычный» режим. Так вот первый режим требует в ответе опции 60 со значением PXEClient, иначе тоже игнорирует офферы.
Послушайте трафик, там есть опция, кажется, 54, Parameter LIst называется, там указан список опций, которые хочет видеть сетевуха. Сравните этот список с тем, что вы предоставляете и, может быть, это и будет решением.
опции 60 со значением PXEClient, иначе тоже игнорирует офферы.
Мм, а я это только для HTTPClient отдаю, спасибо!
А не было такого, что во "втором" режиме из-за vendor-class-identifier=PXEClient сетевухи перестают из ROM-а в iPXE грузиться? А то как бы не оказалось, что починю опять половину хостов, а сломается вторая половина -)
Пардон, пропустил уведомление о комментарии.
Тут, кажется, вам только эксперименты помогут. Я в своей работе в принципе не отдаю опцию 60, так загружается самый простой режим, который (по крайней мере у меня) работает.
Когда я пытался отвечать с PXEClient, то сетевуха по спецификации делает ещё один DHCPproxy-запрос юникастом на другой порт. В общем, меня такое поведение не радовало и поэтому я не использую опцию 60.
Ультимативные крестики-нолики и iPXE