Le DHCP est un élément de base dans une architecture desktop mais également sur une architecture cloud. Perdre son DHCP signifie généralement perdre la connectivité à posteriori au sein de l’entreprise ou du datacenter cloud. Il convient de définir un failover, autrement dit, une redondance du DHCP.
Le protocole VRRP/CARP/HSRP permet de maintenir le lien avec des services à IP statiques, mais le DHCP utilise une configuration réseau bien particulière qui engendre des conflits si jamais deux d’entre eux cohabitent sur un réseau. Il convient alors d’utiliser un module implémenté dans l’architecture ISC-dhcpd, le failover.
Ce failover joue sur un système de priorités et de maître esclave. Voyons comment le configurer.
Afin de configurer le failover nous allons utiliser une nouvelle classe ISC, le failover peer. Avant d’aller dans les détails voici une configuration de pair maître, qui sera détaillée juste en dessous. Pour rappel le pair maître est le DHCP maître, celui qui répondre aux requêtes DHCP et qui sera mis en failover en cas de panne.
failover peer "dhcp-failover" {
primary; # declare this to be the primary server
address 10.1.1.1;
port 54054;
peer address 10.1.1.2;
peer port 54054;
max-response-delay 3;
max-unacked-updates 2;
load balance max seconds 3;
mclt 1800;
split 128;
}
Nous définissons ci-dessus l’objet “dhcp-failover” de classe failover peer. Nous aurions pu changer son nom, notamment si on souhaite répartir la charge sur différents serveurs.
Dans cet objet nous avons les directives suivantes :
Maintenant configurons le failover sur le pair. La configuration est quasiment identique. Les attributs mclt et split disparaissent et primary devient donc secondary.
failover peer "dhcp-failover" {
secondary; # declare this to be the primary server
address 10.1.1.2;
port 54054;
peer address 10.1.1.1;
peer port 54054;
max-response-delay 3;
max-unacked-updates 2;
load balance max seconds 3;
}
Maintenant que l’objet de failover est définit dans la configuration il faut l’appliquer aux pools d’adresses délivrés. Si votre configuration n’est pas architecturée en pool ou est simple, il va faloir la revoir. Pour rappel l’objet pool est une classe du subnet.
Petit exemple de configuration d’un subnet et son pool d’adresses :
subnet 10.1.2.0 netmask 255.255.255.0 {
option routers 10.1.2.254;
option domain-name "entreprise.local";
pool {
range 10.1.2.130 10.1.2.250;
# on définit le subnet en failover
failover peer "dhcp-failover";
host pc-de-maurice {
hardware ethernet c4:2c:4a:05:67:9d;
fixed-address 10.1.2.3;
}
host pc-de-francis {
hardware ethernet d4:d5:20:a9:cc:2a;
fixed-address 10.1.2.17;
}
}
}
Notre pool de classe C sera donc définit comme utilisant un failover configuré sur le modèle “dhcp-failover”. Si jamais le primaire venait à tomber le réseau serait automatiquement redistribué par le secondaire.
Nous pouvons désormais définir le DHCP comme étant en failover, mais une petite chose à été oubliée, les deux DHCP doivent avoir la même configuration afin de pouvoir distribuer le même réseau.
Via le protocole rsync (apt-get install rsync) nous allons synchroniser la configuration de nos deux DHCP. Il est suggéré de synchroniser dans les deux sens afin de ne pas perdre la configuration modifiée sur le failover.
Sur le pair secondaire, nous allons synchroniser périodiquement, via le cron la configuration des deux DHCP. Ajoutons la ligne :
*/10 * * * * root /root/dhcp-sync.sh
Le bash dhcp-sync.sh contiendra les deux lignes importantes de synchronisation :
#! /bin/bash
rsync -Haurov --stats --delete --backup --backup-dir=/root/bck/
user1@dhcp.fss.com:/etc/dhcp/dhcpd.conf /etc/dhcp/
service isc-dhcp-server force-reload
Avec ces deux modifications nous allons toutes les 10 minutes synchroniser la configuration du DHCP, et faire le backup de celle-ci.
Cette méthode est assez rudimentaire, je vous suggère d’utiliser un outil comme Ansible ou Puppet afin de synchroniser ces configurations statiques.
Votre DHCP failover est opérationnel, vous pourrez désormais parer à toute panne de DHCP.
Attention ! N’oubliez pas, si votre DHCP est dans un VLAN différent d’ajouter les options DHCP relay qui vont bien sur vos routeurs afin que le DHCP en failover puisse lui aussi répondre.