DHCP – Configuration ISC DHCP3 redondé

Introduction

Ce document va expliquer la configuration redondé de deux serveurs ISC DHCP3.

Le principe est que la plage dynamique est coupée en deux entre les deux serveurs ISC DHCP3 et chacun répond sur sa partie. Quand l’un des deux serveurs ne fonctionne plus, l’autre prend tout la plage d’adresses pour lui pendant un certain temps. Pour les adresses IP fixes, elles doivent être déclarées sur les deux serveurs.

Cela s’applique aussi bien à une distribution Linux, testé sur Debian Sarge, que sur FreeBSD, testé en 6.1.

 

Prérequis

Il faudra avoir installé le paquet dhcp3-server sur une Debian et les configurations se passeront dans /etc/dhcp3/. Sur FreeBSD, il faudra installer le port isc-dhcp3-server, le fichier de configuration est par défaut dans /usr/local/etc/.

Cela est biensûr à appliquer sur les deux serveurs !

Dans la suite du document, tout sera basé un FreeBSD.

La configuration est très semblable à celle d’un serveur ISC DHCP3 normal. Mais il faut ajouter une section de type failover sur chaque serveur DHCP pour lui indiquer avec qui il gère le ou les réseaux en question. Ensuite on utilisera ce failover sur les différentes plages dynamiques.

Pour la configuration normale d’un serveur ISC DHCP3, vous pouvez vous reporter au document suivant: Configuration ISC DHCP3.

 

Le serveur maître

Sur le serveur maître, il y aura une petite particularité dans la déclaration du failover, on indique quelques paramètres pour la répartition des adresses IP.

Voilà un extrait du fichier de configuration:

[...]
# Déclaration du failover avec son nom
failover peer "dhcp-failover" {
  # ce serveur est le maître
  primary;
  # L'adresse IP local du serveur maître
  address 192.168.1.254;
  # Le port IP local du serveur maître
  port 520;
  # L'adresse IP du serveur esclave
  peer address 192.168.1.253;
  # Le port IP du serveur esclave
  peer port 520;
  # Le temps (en secondes) de pooling pour définir quand le serveur d'en face est mort
  max-response-delay 30;
  # Le nombre de message BNDUPD avant de considérer que le serveur d'en face est mort
  max-unacked-updates 10;
  # Permet d'éviter l'état où un serveur répond aux messages de failover mais plus aux requêtes
  load balance max seconds 3;
  # Pendant combien de temps (en secondes) un serveur DHCP qui a répondu sur l'autre moitié de le plage
  # que la sienne continue-t-il à répondre aux requêtes
  mclt 1800;
  # Cela permet de spécifier comment couper en deux la plage d'adresses dynamiques
  # Il utilise un mécanisme de hashage et 128 permet de mettre autant d'adresses IP sur chaque serveur.
  split 128;
}
[...]

# Une déclaration de réseau
# Le réseau avec son masque
subnet 192.168.1.0 netmask 255.255.255.0 {
[...]
   # Définition d'un pool pour utiliser le failover
   pool {
    # Le nom du failover que l'on souhaite utiliser
    failover peer "dhcp-failover";
    # Les clients bootp ne fonctionnent pas avec le failover
    deny dynamic bootp clients;
    # La plage dynamique. Les adresses disponibles vont de 2 à 126 inclus
    range 192.168.1.2 192.168.1.126;
   }
[...]

La configuration du serveur maître est maintenant terminée.

 

Le serveur esclave

Le serveur esclave se configure de la même façon, sauf qu’il ne faut pas lui mettre les paramètres mclt et split car c’est le serveur maître qui impose ces options !

Voici un extrait du fichier de configuration:

[...]
# Déclaration du failover avec son nom
failover peer "dhcp-failover" {
  # ce serveur est l'esclave
  secondary;
  # L'adresse IP local du serveur maître
  address 192.168.1.253;
  # Le port IP local du serveur maître
  port 520;
  # L'adresse IP du serveur esclave
  peer address 192.168.1.254;
  # Le port IP du serveur esclave
  peer port 520;
  # Le temps (en secondes) de pooling pour définir quand le serveur d'en face est mort
  max-response-delay 30;
  # Le nombre de message BNDUPD avant de considérer que le serveur d'en face est mort
  max-unacked-updates 10;
  # Permet d'éviter l'état où un serveur répond aux messages de failover mais plus aux requêtes
  load balance max seconds 3;
}
[...]

# Une déclaration de réseau
# Le réseau avec son masque
subnet 192.168.1.0 netmask 255.255.255.0 {
[...]
   # Définition d'un pool pour utiliser le failover
   pool {
    # Le nom du failover que l'on souhaite utiliser
    failover peer "dhcp-failover";
    # Les clients bootp ne fonctionnent pas avec le failover
    deny dynamic bootp clients;
    # La plage dynamique. Les adresses disponibles vont de 2 à 126 inclus
    range 192.168.1.2 192.168.1.126;
   }
[...]

Notre serveur esclave est maintenant configuré.

 

Application des modifications

Il ne reste plus qu’à redémarrer les services DHCP sur les deux serveurs. Il est conseillé pour un premièr démarrage de démarrer le serveur esclave puis le maître. Dans les deux cas, la commande est la suivante:

# /usr/local/etc/rc.d/isc-dhcpd restart

 

Mot de la fin

Nous voici donc avec deux serveurs ISC DHCP3 qui servent le ou les mêmes réseaux car il est biensûr possible d’utiliser notre déclaration de failover pour plusieurs réseaux.

Il est tout à fait possible aussi de déclarer plusieurs failover sur un seul serveur. Cela peut-être utilise dans le cas d’un serveur DHCP qui est le backup de plusieurs autres serveurs DHCP.

La plus grosse contrainte est de maintenir les deux configurations à jour, surtout pour les déclarations statiques. Pour remédier à cela, on peut utiliser un stockage en LDAP des configurations des serveurs ISC DHCP3. Pour cela, vous pouvez vous reporter au document suivant: Configuration ISC DHCP3 en backend LDAP.

 

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s