DHCPDISCOVER / DHCPOFFER, mais pas de DHCPACK
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;
}
}
Ç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 envoi individuel 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 trouve son chemin vers le client et si c'est le cas, pourquoi le client n'est-il pas DHCPREQUEST: ing l'adresse.
n agent de relais DHCP commun est l'option "ip helper-address" dans les commutateurs Cisco sous une interface spécifique.
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 couvre plusieurs commutateurs L2 interconnectés avec divers liens "trunk" ( 802.1q ), j'ai rencontrer des problèmes similaires en cas de non-concordance entre la configuration d'au moins une liaison de jonction.
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 est [ ~ # ~] pas [~ # ~] recevant le DHCP-OFFER et, par conséquent, réédite le message DHCP-DISCOVER. 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: 
la 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 de la jonction (ou du serveur DHCP au client DHCP), N'EST PAS TAGUÉ;
- 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 VLAN du port de jonction de SW B, le client DHCP ne pas recevra les paquets de Serveur DHCP.
Ceci est très facile à dépanner, si vous "contrôlez" l'hôte 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>
affichera si le client reçoit ou non le DHCP-OFFER du DHCP-SERVER.
Les choses sont plus difficiles à dépanner si vous pouvez ne pas contrôler le côté client.
PS: De toute évidence, les problèmes ci-dessus, ainsi que d'autres arguments connexes, peuvent être facilement évités en utilisant les technologies appropriées (comme GVRP , VTP ou autre approche de configuration non strictement manuelle) mais ... cela sort du cadre de cette réponse
Eu le même problème. Ne voyant aucun DHCPACK. Le problème ici était:
disque plein
dhcpd n'a pas pu écrire dans /var/lib/dhcp/dhcpd.leases.
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.
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 du boîtier virtuel é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 le serveur DHCP vm. Les journaux montrent que le serveur reçoit la demande du client mais le client obtient son ip de vb à la place pour que vous ne receviez jamais un ACK renvoyé au serveur.
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