C’est pourquoi j’avais exclu les cas de failover (qui consiste en effet à faire de l’overlapping, mais avec une config particulière). Un client ne peut pas sélectionner un serveur au début de sa requête car par défaut, il envoie un message à FF:FF:FF:FF:FF:FF. C’est après le DISCOVER/OFFER qu’il va choisir le serveur via le DHCPREQUEST: i.e. le premier qu’il reçoit. Ce qui n’empêche pas qu’il reçoive des messages de plusieurs serveur, mais ne tiendra compte que du premier.
Ce message est envoyé après le DISCOVER et le OFFER, donc après la définition du serveur qui sera pris en compte. C’est dans le DISCOVER/OFFER (où se fait le choix du serveur) que le problème se pose. A ce moment là aucun serveur n’est défini donc le client n’a pas fait de choix. C’est après l’OFFER, où, à moins d’une configuration explicite de refus d’un serveur, le client va prendre le premier qui lui aura fait une offre.
Ce choix se fait en envoyant ensuite ses requêtes uniquement au serveur en question (via le DHCPREQUEST justement). D’où le rejet implicite des autres serveur, non pas en rejetant leurs messages, mais tout simplement en ne communicant pas avec eux.
J’implémente des serveurs DHCP depuis plus de 20 ans avec au départ la RFC 1531 puis la 2131 (pas loin d’une centaine de configuration depuis, le premier implémenté dans les années 90 , et le premier incident classique auquel on fait généralement face, c’est justement celui de la présence de deux serveurs DHCP sans liens entre eux, qui foutent le bazar dans un réseau). j’en faisais même une conférence (avec DNS) dans des réunions organisées par le LUG Parinux dont je faisais parti.
le fait d’avoir deux serveurs DHCP sur un même brin réseau est d’ailleurs un moyen de compromission du brin réseau.
