У меня есть удаленный клиентский компьютер, который отправляет DHCPDISCOVER. Сервер отвечает DHCPOFFER, но DHCPACK отсутствует.
Это повторяется примерно каждые 30 секунд с того же хоста. Есть ли что-то, что я могу сделать удаленно, или мне нужно, чтобы кто-нибудь перезагрузил его? Он находится в центре обработки данных, поэтому мне, возможно, придется поехать туда, чтобы сделать это!
Спасибо за предложения. Я перезагружал все машины, но у меня все еще есть проблемы. Я думаю, что есть проблема с моей конфигурацией. Это выглядит правильно?
#
# /etc/dhcpd.conf for primary DHCP server
#
authoritative;
ddns-update-style none;
deny duplicates;
default-lease-time 600;
max-lease-time 3600;
# Our fixed hosts
host host2 { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.202; }
host host3 { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.203; }
host host4 { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.204; }
host host5 { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.205; }
subnet x.x.x.128 netmask 255.255.255.128 {
option subnet-mask 255.255.255.128;
option broadcast-address x.x.x.255;
option routers x.x.x.129;
option domain-name-servers 8.8.8.8, 8.8.4.4;
# Testing pool.
pool {
max-lease-time 300; # 5 minutes
range x.x.x.250 x.x.x.254;
deny known-clients;
}
# Our hosts - I didn't have this pool declaration before, do I need it if I want
# the hosts to be running dhcp but always get the same address?
pool {
max-lease-time 1800;
range x.x.x.200 x.x.x.220;
deny unknown-clients;
}
}
Ответы:
Идет:
Вы пропускаете DHCPREQUEST до DHCPACK в вашем описании.
Если клиент находится в другой подсети, чем сервер DHCP, DHCPOFFER отправляется в одноадресном режиме на ретранслятор DHCP через порт 67 UDP. Агент DHCP-ретрансляции передает DHCPOFFER в подсеть на UDP-порт 68.
Я бы исследовал проблемы с подключением, связанные с DHCPOFFER. Отследите это и посмотрите, находит ли он свой путь обратно к клиенту, и если это так, почему клиент не DHCPREQUEST: адрес.
Распространенным агентом ретрансляции dhcp является опция «ip helper-address» в коммутаторах cisco под конкретным интерфейсом.
источник
Предположим, что ваш DHCP-сервер и DHCP-клиент оба подключены к одному и тому же сегменту Ethernet, и предположим, что такой сегмент Ethernet охватывает несколько L2-коммутаторов, соединенных с различными «магистральными» ( 802.1q ) ссылками, я столкнулся с похожими проблемами, когда были несоответствие между конфигурацией хотя бы одного магистрального канала.
В деталях, бесконечный цикл DHCP-DISCOVER / DHCP-OFFER (как видно со стороны DHCP-сервера), позвольте мне думать, что DHCP-клиент НЕ получает DHCP-OFFER и, следовательно, придерживаться перевыпуска DHCP -Открытие сообщения. Такой DHCP-DISCOVER (как видно со стороны DHCP-клиента) правильно получен от DHCP-сервера.
Учитывая следующий сценарий:
неправильная / несоответствующая настройка двух магистральных портов означает, что:
Это очень легко устранить, если вы «управляете» хостом DHCP-клиента. В таком случае, предположим, что eth0 - это сетевой интерфейс, используемый хостом DHCP-клиента, простой:
покажет, получит ли клиент DHCP-предложение от DHCP-сервера или нет.
Сложнее разобраться, если вы не можете контролировать клиентскую часть.
PS: Очевидно, что вышеизложенных проблем, а также других связанных с этим аргументов можно легко избежать, используя надлежащие технологии (такие как GVRP , VTP или другой не строго ручной подход к настройке), но ... это выходит за рамки этого ответа
источник
Была такая же проблема. Не видеть никаких DHCPACK. Проблема здесь была:
dhcpd не может писать в
/var/lib/dhcp/dhcpd.leases.источник
Я видел это несколько раз, и пока я видел только две причины:
К счастью, оба должны легко проверяться. Пропингуйте IP-адрес и проверьте соответствующие брандмауэры.
источник
Я изучал брандмауэры, использующие виртуальные блоки, и у меня была похожая проблема, связанная с отсутствием DHCPACK на сервере, и выяснилось, что используются неверные настройки сети виртуальных блоков для тестовой зеленой (внутренней) сети для брандмауэра Ubuntu VM и тестовый клиент Ubuntu VM. Если вы используете сеть NAT, а не внутреннюю сеть vb, клиент vm получает свой ip от vb, а не от сервера vm DHCP. Журналы показывают, что сервер получает запрос от клиента, но вместо этого клиент получает свой ip от vb, поэтому вы никогда не получите ACK, отправленный обратно на сервер.
источник
Для меня это был простой случай забыть отключить DHCP-сервер (через Internet Sharing) на клиенте. Как только я выключил это, аренда DHCP была принята:
источник