Question DHCPDISCOVER / DHCPOFFER, mais pas DHCPACK


J'ai un ordinateur client distant qui envoie DHCPDISCOVER. Le serveur répond avec un DHCPOFFER, mais il n'y a pas de DHCPACK.

Cela se répète environ toutes les 30 secondes à partir du 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 dois y aller pour le faire!


Merci pour les suggestions. Toutes les machines ont été redémarrées, mais j'ai toujours des problèmes. Je pense qu'il y a un problème avec ma configuration. Cela semble-t-il 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;
  }
}

13
2018-01-26 18:09


origine


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 de réseau local que le serveur? Dans le cas contraire, 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 recouvrant une plage dynamique. - Matt


Réponses:


Ça va:

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

Il vous manque le DHCPREQUEST avant le DHCPACK dans votre description.

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

J'étudierais les problèmes de connectivité liés au DHCPOFFER. Suivez-la et voyez si elle parvient au client et si c'est le cas, pourquoi le client n'est-il pas DHCPREQUEST: l'adresse.

Un agent de relais commun DHCP est l’option "ip helper-address" dans les commutateurs cisco sous une interface spécifique.


11
2018-05-29 22:56





En supposant que votre serveur DHCP et votre client DHCP soient tous deux connectés au même segment Ethernet, et en supposant qu'un tel segment Ethernet couvre plusieurs commutateurs L2 interconnectés avec différents "trunk" (802.1q), je me suis heurté à des problèmes similaires en cas de discordance entre la configuration d’au moins une liaison principale.

En détail, le cycle sans fin de DHCP-DISCOVER / DHCP-OFFER (vu du côté du serveur DHCP), laissez-moi penser que le client DHCP est NE PAS recevoir le DHCP-OFFER et, par conséquent, coller à nouveau le message DHCP-DISCOVER. Un tel DHCP-DISCOVER (vu du côté du client DHCP) est correctement reçu du DHCP-SERVER.

Considérant le scénario suivant: enter image description here la mauvaise configuration / incompatibilité des deux ports de ligne principale signifie que:

  • Le trafic VLAN X envoyé par les logiciels A à B dans le tronc (ou du serveur DHCP au client DHCP) est UNTAGGED;
  • Le trafic VLAN X envoyé par le logiciel B à un ordinateur le long de la ligne de réseau (ou du client DHCP au serveur DHCP) est TAGGED.
  • En raison de la configuration native du VLAN du port de liaison du logiciel SW B, le client DHCP ne pas recevoir des paquets du serveur DHCP.

C’est très facile à résoudre, si vous "contrôlez" l'hôte DHCP-Client. Dans un tel cas, à supposer eth0 est l'interface réseau utilisée par l'hôte client DHCP, une simple:

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

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

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

P.S .: Évidemment, 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 une autre approche non-strictement-manuelle-config-)) mais ... ceci sort du cadre de cette réponse


6
2018-01-28 20:49



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


Avait le même problème. Ne pas voir aucun DHCPACK. Le problème ici était:

Disque plein

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


4
2018-01-28 18:27



Merci beaucoup. Je voyais découvrir, offrir, demande, demande, demande et aucun ack 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 ceci lorsque je vois un comportement étrange qui commence soudainement. - Rob Fisher


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

  • L'adresse IP fournie par le serveur DHCP est déjà utilisée par un autre périphérique. Habituellement, vous voyez un DHCPNAK cependant.
  • Votre pare-feu accepte le trafic sur le serveur DHCP, mais pas le trafic de retour

Heureusement, les deux devraient être faciles à tester. Cinglez l’adresse IP et vérifiez les pare-feu appropriés.


3
2018-01-26 18:13



Merci. J'ai cinglé l'adresse proposée mais pas de réponse. J'ai ensuite configuré une entrée hôte pour le forcer à proposer une adresse différente, mais cela n'a pas semblé aider. Va vérifier le pare-feu. - Matt


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


0
2017-12-11 17:37