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;
}
}
Réponses:
Ça va:
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.
la source
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:
une configuration incorrecte / non adaptée des deux ports de jonction signifie que:
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:
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
la source
Eu le même problème. Ne voyant aucun DHCPACK. Le problème ici était:
dhcpd n'a pas pu écrire
/var/lib/dhcp/dhcpd.leases.la source
Je l'ai vu plusieurs fois et jusqu'à présent, je n'ai vu que deux raisons:
Heureusement, les deux devraient être faciles à tester. Envoyez un ping à l'adresse IP et vérifiez les pare-feu appropriés.
la source
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.
la source
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é:
la source