Qu'est-ce qu'un client DHCP considère comme la «meilleure» réponse?

Nous avons des salles de formation où normalement Windows XP est installé (via PXE). L'infrastructure DNS / DHCP "normale" est constituée de serveurs Windows. La salle de formation a son propre VLAN (différent des serveurs Windows), il y a donc très probablement un assistant IP pour les requêtes DHCP actives sur le routeur Cisco auquel tous les PC de cette salle sont connectés.

Maintenant, nous voulions plutôt convertir certains PC en Linux. L'idée était: mettre notre propre ordinateur portable avec un serveur DHCP dans le VLAN de la pièce et remplacer la réponse DHCP "normale". L'idée était que cela devrait fonctionner, puisqu'un serveur DHCP directement connecté dans ce VLAN devrait avoir un temps de réponse plus rapide que le serveur DHCP "normal" situé à quelques sauts de ce VLAN.

Il s'est avéré que cela n'a pas fonctionné. Nous avons dû libérer manuellement le bail sur le serveur DHCP d'origine pour le faire fonctionner.

Sur l'ordinateur portable, nous avons vu le client demander l'IP et "notre" dhcp envoyait des NACK à la demande IP de Windows, avant de proposer notre propre réponse.

Vieille question: pourquoi cela n'a-t-il pas fonctionné comme prévu? Qu'est-ce qui fait que le PC retrouve son ancien bail?

Mise à jour 2012-08-08:

Le problème de regain a été expliqué dans le DHCP-RFC. Maintenant, cela explique pourquoi le PC retrouve son ancien bail.

Maintenant, nous libérons l'IP du serveur Windows-DHCP avant de faire un nouvel essai.

Encore une fois - le serveur Windows-DHCP gagne.

Je soupçonne qu'il existe un algorithme pour le client dhcp qui détermine la "meilleure" réponse dhcp pour le client. La nouvelle question est:

Comment le client choisit-il la "meilleure" réponse?

C'est le fournisseur, même le micrologiciel spécifique, comment un client réagit à plusieurs réponses DHCP.

Les variantes que j'ai vues au fil des ans sont:

1) Acceptez le premier, qu'il s'agisse d'un ACK ou d'un NACK.

2) Prenez le premier ACK, ignorez complètement NACK.

3) Prenez le dernier ACK reçu dans un intervalle de temps défini (généralement 5 à 10 secondes).

Exemple: il y a quelques années, nous avons eu des problèmes avec les multifonctions Ricoh.
Nous avions 2 serveurs DHCP. L'un a fourni les adresses, l'autre uniquement des options DHCP supplémentaires. Le 2ème serveur a toujours répondu en premier.
La variante utilisée par Ricoh 1) même si la 1ère offre ne contenait que des options DHCP. Ricoh l'a changé pour la variante 2) avec une mise à jour du firmware après que nous leur avons expliqué le problème.

En supposant que le routeur agit toujours comme un relais DHCP et que vous transmettez la demande à votre serveur d'origine, la raison pour laquelle il l'a fait est simplement parce que le serveur DHCP de Windows lui a dit d'aller de l'avant et d'utiliser l'IP. Dans ce cas, le DHCPNACK du nouveau serveur n'est pas pertinent, car un client DHCP considérera toutes les réponses, et puisqu'il a reçu une offre de la boîte DHCP de Windows, il est parfaitement heureux de l'utiliser.

PC: Oh salut, puis-je utiliser 192.168.1.123?

Nouveau DHCP: je dis non.

Old-DHCP: Je dis oui.

PC: Quelqu'un a dit oui! Doux, je vais l'utiliser!

Si rien d'autre n'aide - RTFM (lire le manuel fin). Dans ce cas, le premier a été le coup.

La RFC 2131 décrit les opérations DHCP.

La section 1.6 stipule que DHCP doit :

Conserver la configuration du client DHCP lors des redémarrages du serveur et, dans la mesure du possible, un client DHCP doit se voir attribuer les mêmes paramètres de configuration malgré les redémarrages du mécanisme DHCP,

Maintenant, la question intéressante est de savoir comment cet objectif de conception est atteint sur un client qui n'a aucune connaissance de son passé. La section 3.2 décrit:

3.2 Interaction client-serveur - réutilisation d'une adresse réseau précédemment allouée

Si un client se souvient et souhaite réutiliser une
adresse réseau précédemment allouée , un client peut choisir d'omettre certaines des étapes
décrites dans la section précédente. Le diagramme de chronologie de la figure 4
montre les relations de synchronisation dans une interaction client-serveur typique pour un client réutilisant une adresse réseau précédemment allouée.

1. Le client diffuse un message DHCPREQUEST sur son sous-réseau local. Le message inclut l'adresse réseau du client dans l'option «adresse IP demandée». Comme le client n'a pas reçu son adresse réseau, il NE DOIT PAS remplir le champ 'ciaddr'. Les agents de relais BOOTP transmettent le message aux serveurs DHCP ne se trouvant pas sur le même sous-réseau. Si le client a utilisé un «identifiant client» pour obtenir son adresse, le client DOIT utiliser le même «identifiant client» dans le message DHCPREQUEST.

2. Les serveurs connaissant les paramètres de configuration du client répondent par un message DHCPACK au client. Les serveurs NE DEVRAIENT PAS vérifier que l'adresse réseau du client est déjà utilisée; le client peut répondre aux messages de demande d'écho ICMP à ce stade.

Ainsi, un serveur DHCP détenant un bail actif a la priorité en utilisant un raccourci dans le protocole.

1. Client: DHCREQUEST (MAC-Adress, broadcast, sera transmittet dans le domaine de diffusion local - ici le VLAN local et via IP-helper au serveur Windows-DHCP)
2. Serveur DHCP pour ordinateur portable: DHCPOFFER
3. Windows-DHCP-Server: Hé - je vous connais déjà - DHCPACK
4. Client: Oh - j'ai eu deux réponses. Celui qui me connaît déjà. Cool je vais prendre ça

A partir de là, le serveur DHCP pour ordinateur portable est ignoré par le client.

Donc, la solution dans notre cas sera probablement (je mettrai à jour cela lorsque nous le testerons réellement):

1. Assurez-vous que le client est éteint
2. Désactivez le serveur DHCP sur l'ordinateur portable, le faux client-MAC sur l'ordinateur portable, la demande DHCP
3. Release IP
4. Récupérez l'IP et le MAC d'origine, activez le serveur DHCP
5. Allumez le client et faites un démarrage PXE ...

La nouvelle question devrait probablement être dans une question différente - le titre de la question ne correspond pas du tout à la plupart du corps de la question.

Dans tous les cas, en ce qui concerne la façon dont un client choisit quelle offre, dans le cas où il n'a pas de bail en cours: c'est au client, mais dans chaque implémentation de client DHCP que je connais, c'est une course simple .

La RFC 2131 couvre ceci:

Les clients DHCP sont libres d'utiliser n'importe quelle stratégie pour sélectionner un serveur DHCP parmi ceux dont le client reçoit un message DHCPOFFER.

Il y a un brouillon IETF qui semble mort qui aurait ajouté de la configurabilité au processus de sélection, et mentionne également les implémentations de client terne (d'il y a plus d'une décennie, mais peu de choses ont changé):

Dans la pratique, la mise en œuvre de la politique de la plupart des fournisseurs ici est très basique (par exemple, première offre reçue ou première offre acceptable reçue) et est "codée en dur" (c'est-à-dire non configurable).

Le fait d'avoir deux serveurs DHCP fournissant un service au même réseau avec une configuration différente se traduit par des courses, ce qui n'est pas souhaitable du point de vue de la fiabilité ou de la prévisibilité. Il n'y a vraiment aucune raison pour laquelle vous ne pouvez pas obtenir votre seul serveur DHCP pour fournir ce dont vous avez besoin.