DHCPDISCOVER / DHCPOFFER, mais pas de DHCPACK

17

J'ai une machine cliente distante qui envoie des DHCPDISCOVER. Le serveur répond avec un DHCPOFFER, mais il n'y a pas de DHCPACK.

Cela se répète toutes les 30 secondes environ depuis le même hôte. Puis-je faire quelque chose à distance ou dois-je demander à quelqu'un de le redémarrer? C'est dans un centre de données donc je vais peut-être devoir y aller pour le faire!

Merci pour les suggestions. J'ai redémarré toutes les machines, mais j'ai toujours des problèmes. Je pense qu'il y a un problème avec ma configuration. Est-ce que cela semble correct?

#
# /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;
  }
}
linux  isc-dhcp  dhcpd 
— Mat
source
DHCPRequest devrait venir avant le DHCPAck. Voyez-vous cela? Essayez d'exécuter une capture de paquets sur le serveur et recherchez DHCPDiscover, DHCPOffer, DHCPRequest et DHCPAck vers et depuis le serveur. Le client est-il sur le même segment LAN que le serveur? Sinon, le routeur séparant les deux est-il configuré en tant que relais DHCP?
— joeqwerty
Il s'est avéré que le problème était dû à une mauvaise configuration. J'avais une plage statique chevauchant une plage dynamique.
— Matt

Réponses:

14

Ça va:

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

Vous vous manquez le DHCPREQUEST avant le DHCPACK dans votre description.

Si le client se trouve sur un sous-réseau différent du serveur DHCP, le DHCPOFFER est envoyé en monodiffusion au relais DHCP sur le port 67 UDP. L'agent de relais DHCP diffuse le DHCPOFFER au sous-réseau sur le port UDP 68.

J'enquêterais sur les problèmes de connectivité liés au DHCPOFFER. Suivez-le et voyez s'il retrouve son chemin vers le client et si c'est le cas, pourquoi le client n'est-il pas DHCPREQUEST: ing l'adresse.

Un agent de relais DHCP commun est l'option «ip helper-address» dans les commutateurs Cisco sous une interface spécifique.

— artifex
source
10

En supposant que votre serveur DHCP et votre client DHCP sont tous deux connectés au même segment Ethernet, et en supposant que ce segment Ethernet s'étend sur plusieurs commutateurs L2 interconnectés avec diverses liaisons "trunk" ( 802.1q ), j'ai rencontré des problèmes similaires lorsqu'il y avait une non-concordance entre la configuration d'au moins une liaison interurbaine.

En détail, le cycle sans fin de DHCP-DISCOVER / DHCP-OFFER (vu du côté du serveur DHCP), permettez-moi de penser que le client DHCP ne reçoit pas le DHCP-OFFER et, par conséquent, réédite le DHCP -Découvrir le message. Un tel DHCP-DISCOVER (vu du côté du client DHCP) est correctement reçu du DHCP-SERVER.

En considérant le scénario suivant: entrez la description de l'image ici une configuration incorrecte / non adaptée des deux ports de jonction signifie que:

  • Le trafic VLAN X envoyé par SW A vers SW B le long du joncteur réseau (ou du serveur DHCP au client DHCP), N'EST PAS MARQUÉ;
  • Le trafic VLAN X envoyé par SW B vers SW A le long de la jonction (ou du client DHCP au serveur DHCP), est TAGGED.
  • en raison de la configuration native du VLAN du port de jonction de SW B, le client DHCP ne recevra pas de paquets du serveur DHCP.

C'est très facile à dépanner, si vous "contrôlez" l'hôte du client DHCP. Dans un tel cas, en supposant que eth0 est l'interface réseau utilisée par l'hôte client DHCP, un simple:

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

montrera si le client reçoit ou non le DHCP-OFFER du DHCP-SERVER.

Les choses sont plus difficiles à dépanner si vous ne pouvez pas contrôler le côté client.

PS: Évidemment, les problèmes ci-dessus, ainsi que d'autres arguments connexes, peuvent être facilement évités en utilisant des technologies appropriées (comme GVRP , VTP ou autre approche de configuration non strictement manuelle) mais ... cela sort du cadre de cette réponse

— Damiano Verzulli
source
Il semblerait que cela puisse également se produire à la suite d'un bogue logiciel dans le serveur DHCP, lorsque l'interface côté serveur est pontée sur différents VLAN.
— DustWolf
6

Eu le même problème. Ne voyant aucun DHCPACK. Le problème ici était:

Disque plein

dhcpd n'a pas pu écrire /var/lib/dhcp/dhcpd.leases.

— 1977er
source
Merci beaucoup. Je voyais découvrir, offrir, demander, demander, demander et aucun accusé de réception et c'était la cause. Il n'y avait rien non plus dans / var / log / syslog, pour la même raison. Il est temps que j'apprenne à vérifier cela en premier lorsque je vois un comportement étrange qui se déclenche soudainement.
— Rob Fisher du
3

Je l'ai vu plusieurs fois et jusqu'à présent, je n'ai vu que deux raisons:

  • L'adresse IP donnée par le serveur DHCP est déjà utilisée par un autre appareil. Habituellement, vous verriez un DHCPNAK.
  • Votre pare-feu accepte le trafic vers le serveur DHCP, mais pas le trafic de retour

Heureusement, les deux devraient être faciles à tester. Envoyez un ping à l'adresse IP et vérifiez les pare-feu appropriés.

— Dennis Kaarsemaker
source
Merci. J'ai cinglé l'adresse proposée mais aucune réponse. J'ai ensuite mis en place une entrée d'hôte pour le forcer à proposer une adresse différente mais cela ne semble pas aider. Vérifie le pare-feu.
— Matt
0

J'ai appris des pare-feu utilisant une boîte virtuelle et j'ai eu un problème similaire de ne pas obtenir le DHCPACK sur le serveur et il s'est avéré que les paramètres réseau de la boîte virtuelle étaient incorrects pour le réseau de test vert (interne) pour un pare-feu ubuntu vm et un test de client ubuntu vm. Si vous utilisez le réseau NAT plutôt que le réseau interne vb, le client vm obtient son ip de vb plutôt que du serveur DHCP vm. Les journaux montrent que le serveur reçoit la demande du client, mais le client obtient son adresse IP à partir de vb, de sorte que vous ne recevez jamais un ACK renvoyé au serveur.

— Mark Simmons
source
0

Pour moi, il s'agissait simplement d'oublier d'éteindre le serveur DHCP (via le partage Internet) sur le client. Dès que j'ai désactivé cela, le bail DHCP a été accepté:

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
— Heath Raftery
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.