Назад | Перейти на главную страницу

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-relay передает 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-DISCOVER. Такой DHCP-DISCOVER (со стороны DHCP-клиента) правильно получен от DHCP-SERVER.

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

  • Трафик 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-СЕРВЕРА или нет.

Устранить неполадки труднее, если вы можете не контролировать клиентскую сторону.

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

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

диск полон

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

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

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

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

Я узнал о брандмауэрах с использованием виртуального ящика, и у меня была аналогичная проблема с отсутствием DHCPACK на сервере, и оказалось, что я использовал неправильные сетевые настройки виртуального ящика для тестовой зеленой (внутренней) сети для брандмауэра ubuntu vm и тестовый клиент ubuntu vm. Если вы используете сеть NAT, а не внутреннюю сеть vb, клиент vm получает свой IP от vb, а не от DHCP-сервера vm. Журналы показывают, что сервер получает запрос от клиента, но вместо этого клиент получает свой 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