bonjour,
quelqu’un a-t-il déjà jeté un oeil à Kea, le nouveau server DHCP de ISC?
Je viens de regarder la description,
Ça ne serait pas aussi utilisé pour la répartition de charges dans des cas précis ?
Plutôt de la gestion de congestion en fait.
De la répartition de charge, ça serait une bonne idée d’intégrer ça dans un serveur DHCP, avec un système de failover. Genre, si un des serveurs plante, un autre peut prendre la relève comme s’il ne s’était rien passé.
de la repartition de charge sur un protocole comme le DHCP ca ne sert à rien; quand au failover ca existe deja en fait.
Quant au failover.
Je ne connais que dnsmasq et le serveur ISC-DHCP. Je ne savais pas qu’il en existait un autre qui gérait le failover.
il semble que Kea le fasse aussi, ce qui porte à deux avec ISC-DHCP.
Pour la réoartition de charge j’ai répondu vite.
Pour faire de la répartition de charge il faut un minimum de persistance de connexion. Ce qui n’est pas le cas de UDP. En prime, la particularité du protocole DHCP c’est que la gestion de la communication est gérée par le client et non par le serveur, d’où les messages broadcastés. Donc pas moyen de faire de la répartition de charge dessus.
Je ne comprends pas ta phrase, ISC-DHCP ne fait pas de failover, le mieux que tu peux avoir, c’est qu’un serveur secondaire prenne en charge le DHCP quand le primaire est down.
Je disais que je ne connaissais pas d’autres serveurs DHCP, et encore moins un qui gère le failover correctement. Si tu me dis que Kea le fait, s’il gère aussi la mise à jour du DNS, je vais chercher de ce côté, parce qu’ISC-DHCP est très bien, mais avec la mise à jour du DNS proposé par dnsmasq et le failover que je n’ai jamais vu, ça risque de donner quelque chose.
C’est le principe de base du failover.
ISC-DHCP fait très bien la mise à jour du DNS, en tout cas en IPv4. j’ai un probleme en IPv6 pour le moment (pas de mise à jour mais pas de message d’erreur non plus…)
Non, le principe du failover, c’est que ça se passe comme s’il ne s’était rien passé. Le failover d’ISC-DHCP, ce sont des clients qui changent d’adresse IP sans aucune raison. Enfin, sans aucun raison, si, je sais quelle est la raison, c’est que les baux ne sont pas synchronisés entre les serveurs et que, du coup, chaque instance fait comme il veut.
Et encore, je ne parle pas du cas de son intégration dans PfSense, parce que ce n’est pas le sujet.
ben https://kb.isc.org/docs/aa-00502
me semble que le problème ne se pose plus aujourd’hui non?
EDIT: je confirme pour Pfsense comme pour OPNsense. mal fait.
Ah, ben, c’est récent, ça date de l’an dernier. Du coup, je peux sans doute essayer de nouveau de le mettre en œuvre, si j’ai le courage de comprendre la logique de ce truc.
Pour celleux qui ne connaissent pas, l’implémentation du failover du serveur DHCP dans PfSense, c’est que tous les nœuds répondent aux requêtes DHCP en même temps et que le client choisi le premier qu’il reçoit. Ce qui fait que les baux sont plus ou moins répartis entre tous les nœuds avec des possibles doublons d’adresses. Et pour la mise à jour du DNS, tu t’asseoir purement et simplement dessus.
en fait, le choix du client de prendre le premier, c’est en fait une des bases du protocole DHCP. C’est un protocole dont la communication est en fait gérée par le client, à la différences des modes clients/serveurs habituels.
Le client broadcast sur le réseau pour connaitre un serveur DHCP.
les serveurs DHCP répondent.
le client choisi le premier et demande une adresse (ou demande l’adresse précédente si les retry/refresh etc… le permettent)
le serveur fait une proposition
le client accepte la proposition
Le serveur valide la prise en compte du choix
Le client se configure et valide la decision du serveur.
le serveur met à jour le DNS.
en fait plusieurs serveurs DNS peuvent très bien mettre à jour le DNS sans problèmes majeurs.
En gros, bien évidement.