DHCPDISCOVER / DHCPOFFER, но без DHCPACK

У меня есть удаленный клиентский компьютер, который отправляет 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;
  }
}

Идет:

CLIENT -> DHCPDISCOVER
SERVER -> DHCPOFFER
CLIENT -> DHCPREQUEST
SERVER -> DHCPACK

Вы пропускаете 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-сервера.

Учитывая следующий сценарий: неправильная / несоответствующая настройка двух магистральных портов означает, что:

• Трафик VLAN X, отправляемый SW A на SW B по транку (или с DHCP-сервера на DHCP-клиент), является НЕЗАКОНЧЕННЫМ;
• Трафик VLAN X, отправленный SW B на SW A вдоль транка (или с DHCP-клиента на DHCP-сервер), помечается.
• из-за собственной настройки VLAN магистрального порта SW B, DHCP-клиент не будет принимать пакеты от DHCP-сервера.

Это очень легко устранить, если вы «управляете» хостом DHCP-клиента. В таком случае, предположим, что eth0 - это сетевой интерфейс, используемый хостом DHCP-клиента, простой:

tcpdump -n -i eth0 ether-host <dhcp-server-mac-address>

покажет, получит ли клиент DHCP-предложение от DHCP-сервера или нет.

Сложнее разобраться, если вы не можете контролировать клиентскую часть.

PS: Очевидно, что вышеизложенных проблем, а также других связанных с этим аргументов можно легко избежать, используя надлежащие технологии (такие как GVRP , VTP или другой не строго ручной подход к настройке), но ... это выходит за рамки этого ответа

Была такая же проблема. Не видеть никаких DHCPACK. Проблема здесь была:

диск полон

dhcpd не может писать в /var/lib/dhcp/dhcpd.leases.

Я видел это несколько раз, и пока я видел только две причины:

• IP-адрес, который дал DHCP-сервер, уже используется другим устройством. Обычно вы увидите DHCPNAK, хотя.
• Ваш брандмауэр принимает трафик к серверу DHCP, но не трафик обратно

К счастью, оба должны легко проверяться. Пропингуйте IP-адрес и проверьте соответствующие брандмауэры.

Я изучал брандмауэры, использующие виртуальные блоки, и у меня была похожая проблема, связанная с отсутствием DHCPACK на сервере, и выяснилось, что используются неверные настройки сети виртуальных блоков для тестовой зеленой (внутренней) сети для брандмауэра Ubuntu VM и тестовый клиент Ubuntu VM. Если вы используете сеть NAT, а не внутреннюю сеть vb, клиент vm получает свой ip от vb, а не от сервера vm DHCP. Журналы показывают, что сервер получает запрос от клиента, но вместо этого клиент получает свой ip от vb, поэтому вы никогда не получите ACK, отправленный обратно на сервер.

Для меня это был простой случай забыть отключить DHCP-сервер (через Internet Sharing) на клиенте. Как только я выключил это, аренда DHCP была принята:

Apr 16 03:54:18 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:54:18 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:54:26 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:54:26 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:34 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:55:34 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:35 dnsmasq-dhcp[5952]: DHCPREQUEST(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:35 dnsmasq-dhcp[5952]: DHCPACK(eth0) 10.0.0.4 40:6c:8f:59:24:8e Heaths-MBP