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 в підмережу на порту 68 UDP.

Я б досліджував проблеми з підключенням, пов’язані з DHCPOFFER. Відстежте його і подивіться, чи знайде він шлях до клієнта, і якщо він є, чому клієнт не DHCPREQUEST: ing адреса.

Поширений агент реле dhcp - це опція "ip helper-address" в комутаторах cisco під певним інтерфейсом.

Припустимо, що ваш DHCP-сервер і DHCP-клієнт підключені до одного сегменту Ethernet, і якщо припустити, що такий сегмент Ethernet охоплює декілька L2-комутаторів, пов'язаних між собою різними "магістральними" ( 802.1q ) посиланнями, я стикався з подібними проблемами, коли не було невідповідність між конфігурацією принаймні однієї магістральної ланки.

Детально, нескінченний цикл DHCP-DISCOVER / DHCP-Offer (як видно зі сторони сервера DHCP), дозвольте мені подумати, що DHCP-клієнт НЕ отримує DHCP-ПРОПОЗИЦІЮ, і, отже, дотримуйтесь переоформлення DHCP -ДИСКОВЕР повідомлення. Такий DHCP-DISCOVER (як видно з боку DHCP-клієнта) правильно отриманий від DHCP-SERVER.

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

• VLAN X трафік, що передається SW A на SW B уздовж магістралі (або з DHCP-сервера до DHCP-клієнта), НЕ ВПРОВАДЖЕН;
• VLAN X трафік, що передається SW B на SW A по магістралі (або від DHCP-клієнта на DHCP-сервер), TAGGED.
• завдяки встановленій 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, а не DHCP-сервера vm. Журнали показують, що сервер отримує запит від клієнта, але клієнт отримує свій ip від vb замість цього, ви ніколи не отримуєте ACK назад на сервер.

Для мене це був простий випадок забути вимкнути сервер DHCP (через Інтернет-обмін) на клієнті. Як тільки я це відключив, оренду 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