ISC DHCP – Serveur DHCP secondaire

ISC DHCP est une implémentation Open Source du protocole DHCP (Dynamic Host Configuration Protocol), sous licence ISC License, écrite à l’origine par Ted Lem, sous contrat avec Vixie Labs, et dont le projet fut financé par l’Internet Systems Consortium (ISC).
La version 1 vit le jour en décembre 1997; elle ne comportait que la version serveur.
La version 2, de juin 1999, ajouta la partie cliente et l’agent de relais BOOTP/DHCP.
La version 3, sortie en octobre 2001 et financée par Nominum Inc., comportait de nombreux ajouts : support de la redondance pour la continuité de service, OMAPI, Dynamic DNS, le comportement conditionnel, la division des clients en classes, et bien plus encore…
La version 4, la dernière en date, sortie en décembre 2007, ajoutait enfin le support de l’IPv6 pour les parties cliente et serveur.

 

Objectif

 
L’objectif de cet article est l’installation et la configuration d’un serveur DHCP secondaire, ou slave, utilisant l’implémentation ISC DHCP, sur une distribution Linux Debian Jessie 8.4 32bits.
 

Schéma logique

 

 

Pré-requis

 

Pré-requis avant réalisation

 

• Un serveur Debian Jessie 8.4 32 bits fonctionnel (installation basique avec utilitaires usuels du système et service SSH) qui hébergera le service DHCP secondaire ou slave
• Un serveur Debian Jessie 8.4 32 bits fonctionnel et configuré comme serveur DHCP primaire ou master
• Packages de base supplémentaires : sudo, resolvconf, aptitude
• Domaine utilisé : opensharing.priv

Rmq : Ici, même si cela ne présente absolument aucun caractère obligatoire, nous utiliserons un serveur DHCP slave hébergeant également un service DNS slave.
 

Installation et configuration du service NTP

Si un failover est mis en place, pour la redondance du service DHCP, il est fondamental que les deux serveurs (master et slave DHCP) soient synchronisés au niveau de l’heure. Le cas échéant, leur communication sera interrompue si le décalage est trop important.
On peut, par exemple, synchroniser le serveur master avec une source externe de temps, et le serveur slave avec le master.
 
Installation du service NTP et de l’utilitaire ntpstat :

# aptitude install ntp ntpstat

Configuration du service NTP :

# nano /etc/ntp.conf

[...]
server dns1.opensharing.priv
server 127.127.0.1
fudge 127.127.0.1 stratum 10 
[...]
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
[...]

# timedatectl set-timezone Europe/Paris
# timedatectl set-ntp true
# systemctl enable ntp
# service ntp restart

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*dhcp1.openshari LOCAL(0)        11 u   34   64   17    0.601  -111.08  80.346

# ntpstat
synchronised to NTP server (192.168.1.11) at stratum 12 
   time correct to within 954 ms
   polling server every 64 s

Le service NTP est bien synchronisé avec le serveur dns1-test.opensharing.priv, qui a pour CNAME dns1.opensharing.priv et dhcp1.opensharing.priv, ce dernier étant synchronisé avec son heure locale.

 

Configuration réseau initiale

 

 

Contenu initial du fichier /etc/network/interfaces :

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
	address 192.168.1.12
	netmask 255.255.255.0
	network 192.168.1.0
	broadcast 192.168.1.255
	gateway 192.168.1.1
	dns-search opensharing.priv
	dns-nameservers 192.168.1.11 127.0.0.1

 

Contenu initial du fichier /etc/hosts :

127.0.0.1	localhost.localdomain	localhost
192.168.1.12	dns2-test.opensharing.priv	dns2-test

Rmq : L’adresse 127.0.1.1 doit être retirée sur un serveur à IP fixe et remplacée par cette dernière, tel que l’exemple ci-dessus.
 
Contenu initial du fichier /etc/host.conf :

order hosts, bind
multi on

 

Contenu initial du fichier /etc/resolv.conf :

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.11
nameserver 127.0.0.1
search opensharing.priv

Rmq :
Le fichier /etc/resolv.conf ne doit pas être édité dès lors que le paquet resolvconf a été installé.

Extrait des enregistrements de la zone DNS opensharing.priv sur le DNS slave (lui-même) :

# cat /var/cache/bind/db.opensharing.priv

[...]
dns2-test	IN	A	192.168.1.12
dns2		IN	CNAME	dns2-test
[...]

 

Réalisation

 

0. Mise à jour préalable du système et des paquets installés

# aptitude update
# aptitude upgrade

 

1. Installation du serveur DHCP

# apt-get install isc-dhcp-server

L’installation du service ISC DHCP génère son fichier de configuration dhcpd.conf dans le répertoire /etc/dhcp/ :

# tree /etc/dhcp/
/etc/dhcp/
├── dhclient.conf
├── dhclient-enter-hooks.d
│   ├── debug
│   └── resolvconf
├── dhclient-exit-hooks.d
│   ├── debug
│   ├── ntpdate
│   └── rfc3442-classless-routes
└── dhcpd.conf

Rmq : La commande tree nécessite l’installation du paquet tree.
 

2. Configuration du serveur DHCP

 

Fichier dhcpd.conf final modifié

include "/etc/bind/tsig.key";

authoritative;
ddns-update-style standard;
update-static-leases off;
ignore client-updates;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;

failover peer "opensharing-failover" {
        secondary;
        address 192.168.1.12;
        port 647;
        peer address 192.168.1.11;
        peer port 647;
        max-response-delay 30; 
        max-unacked-updates 10; 
        load balance max seconds 3;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option routers 192.168.1.1;
	ddns-domainname "opensharing.priv";
	ddns-rev-domainname "in-addr.arpa";
	option domain-name "opensharing.priv";
	option domain-name-servers dns1.opensharing.priv, dns2.opensharing.priv;
	pool {
                failover peer "opensharing-failover";
		range 192.168.1.100 192.168.1.199;
		allow unknown-clients;
	}
	
	group {
		use-host-decl-names true;
		host printer1 { hardware ethernet 01:23:45:00:00:01; fixed-address 192.168.1.200; }
		host printer2 { hardware ethernet 01:23:45:00:00:01; fixed-address 192.168.1.201; }
	}
}

zone opensharing.priv {
	primary 192.168.1.11;
	key "tsig-key";
}

zone 1.168.192.in-addr.arpa. {
	primary 192.168.1.11;
	key "tsig-key";
}

 

Fichier /etc/default/isc-dhcp-server modifié

INTERFACES="eth0"

 

Pour aller plus loin

 

Les étapes de la mise à jour dynamique du DNS sur le master

Scénario :

• Un PC, nommé xptest (en Workgroup) fait une requête DHCP en broadcast
• Son sous-réseau est composé de 2 serveurs DHCP :
• Un serveur DHCP et DNS master : dns1-test.opensharing.priv (192.168.1.11)
• Un serveur DHCP et DNS slave : dns2-test.opensharing.priv (192.168.1.12)

 

1. DORA : DHCPDISCOVER – DHCPOFFER – DHCPREQUEST – DHCPACK

1.1. Sur le master

Aug 15 21:05:54 dns1-test dhcpd: DHCPDISCOVER from 00:11:43:a2:d7:aa via eth0: load balance to peer opensharing-failover
Aug 15 21:05:55 dns1-test dhcpd: DHCPREQUEST for 192.168.1.100 (192.168.1.12) from 00:11:43:a2:d7:aa via eth0: lease owned by peer

1.2. Sur le slave

Aug 15 21:05:54 dns2-test dhcpd: DHCPDISCOVER from 00:11:43:a2:d7:aa via eth0
Aug 15 21:05:55 dns2-test dhcpd: DHCPOFFER on 192.168.1.100 to 00:11:43:a2:d7:aa (xptest) via eth0
Aug 15 21:05:56 dns2-test dhcpd: DHCPREQUEST for 192.168.1.100 (192.168.1.12) from 00:11:43:a2:d7:aa (xptest) via eth0
Aug 15 21:05:56 dns2-test dhcpd: DHCPACK on 192.168.1.100 to 00:11:43:a2:d7:aa (xptest) via eth0

La requête DHCPDISCOVER est envoyée au 2 serveurs DHCP, le master la confie au load-balacing du failover qui tranche en faveur du slave.
Le slave gérera donc la suite de la requête en attribuant un bail au client xptest.
 

2. Mise à jour de la zone directe du DNS master

Le slave s’authentifie auprès du DNS master avec la clef TSIG tsig-key qu’ils partagent afin de lui communiquer les nouveaux enregistrements directs dont il dispose sur son nouveau bail.

2.1. Sur le master

Aug 15 21:05:55 dns1-test named[525]: client 192.168.1.12#16131/key tsig-key: view internal: signer "tsig-key" approved

Le master supprime d’éventuels enregistrements A et DHCID existants pour cet hôte dans la zone directe déclarée dans le fichier dhcpd.conf.
Puis il ajoute, dans la foulée et par requête du slave, les enregistrements A et DHCID relatifs à l’hôte xptest en utilisant les paramètres suivants du bail nouvellement créé sur le slave et synchronisé avec le master :

• ddns-fwd-name (concaténation du client-hostname fourni par le client et du ddns-domainname fourni par le serveur)
• ddns-dhcid
• lease (pour l’IP)

Aug 15 21:05:55 dns1-test named[525]: client 192.168.1.11#65141/key tsig-key: view internal: updating zone 'opensharing.priv/IN': deleting rrset at 'xptest.opensharing.priv' A
Aug 15 21:05:55 dns1-test named[525]: client 192.168.1.12#16131/key tsig-key: view internal: updating zone 'opensharing.priv/IN': adding an RR at 'xptest.opensharing.priv' A
Aug 15 21:05:55 dns1-test named[525]: client 192.168.1.11#65141/key tsig-key: view internal: updating zone 'opensharing.priv/IN': deleting rrset at 'xptest.opensharing.priv' DHCID
Aug 15 21:05:55 dns1-test named[525]: client 192.168.1.12#16131/key tsig-key: view internal: updating zone 'opensharing.priv/IN': adding an RR at 'xptest.opensharing.priv' DHCID

Le service DHCP du slave signifie alors qu’il a bien transmis un nouvel enregistrement pour la zone directe.

2.2. Sur le slave

Aug 15 21:05:56 dns2-test dhcpd: Added new forward map from xptest.opensharing.priv to 192.168.1.100

 

3. Transfert de la zone directe du DNS master vers le slave

Deux nouveaux enregistrements ont été ajoutés à la zone directe sur le DNS master, ils doivent être transmis au DNS slave.
Pour cela, le master signifie une modification de la zone directe au slave en lui envoyant une notification du serial de son SOA tout en s’authentifiant auprès du slave avec la clef TSIG.

3.1. Sur le master

Aug 15 21:05:56 dns1-test named[525]: zone opensharing.priv/IN/internal: sending notifies (serial 2016081467)

Le slave initie alors un transfert de la zone directe.

3.2. Sur le slave

Aug 15 21:05:56 dns2-test named[540]: client 192.168.1.11#23612/key tsig-key: view internal: received notify for zone 'opensharing.priv': TSIG 'tsig-key'
Aug 15 21:05:56 dns2-test named[540]: zone opensharing.priv/IN/internal: Transfer started.
Aug 15 21:05:56 dns2-test named[540]: transfer of 'opensharing.priv/IN/internal' from 192.168.1.11#53: connected using 192.168.1.12#35818
Aug 15 21:05:56 dns2-test named[540]: zone opensharing.priv/IN/internal: transferred serial 2016081467: TSIG 'tsig-key'
Aug 15 21:05:56 dns2-test named[540]: transfer of 'opensharing.priv/IN/internal' from 192.168.1.11#53: Transfer completed: 1 messages, 6 records, 345 bytes, 0.311 secs (1109 bytes/sec)

3.3. Au même moment sur le master

Aug 15 21:05:56 dns1-test named[525]: client 192.168.1.12#35818/key tsig-key (opensharing.priv): view internal: transfer of 'opensharing.priv/IN': IXFR started: TSIG tsig-key
Aug 15 21:05:56 dns1-test named[525]: client 192.168.1.12#35818/key tsig-key (opensharing.priv): view internal: transfer of 'opensharing.priv/IN': IXFR ended

 

4. Mise à jour de la zone inverse du DNS master

Le slave s’authentifie auprès du DNS master avec la clef TSIG tsig-key qu’ils partagent afin de lui communiquer le nouvel enregistrement inverse dont il dispose sur son nouveau bail.

4.1. Sur le master

Aug 15 21:05:56 dns1-test named[525]: client 192.168.1.12#16131/key tsig-key: view internal: signer "tsig-key" approved

Le master supprime d’éventuels enregistrements PTR existants pour cet hôte dans la zone inverse déclarée dans le fichier dhcpd.conf.
Puis il ajoute, dans la foulée et par requête du slave, l’enregistrement PTR relatif à l’hôte xptest en utilisant les paramètres suivants du bail nouvellement créé sur le slave et synchronisé avec le master :

• ddns-rev-name (concaténation de l’IP inversée du client et du ddns-rev-domainname fourni par le serveur)
• lease (pour l’IP)

Aug 15 21:05:56 dns1-test named[525]: client 192.168.1.12#16131/key tsig-key: view internal: updating zone '1.168.192.in-addr.arpa/IN': deleting rrset at '100.1.168.192.in-addr.arpa' PTR
Aug 15 21:05:56 dns1-test named[525]: client 192.168.1.12#16131/key tsig-key: view internal: updating zone '1.168.192.in-addr.arpa/IN': adding an RR at '100.1.168.192.in-addr.arpa' PTR

Le slave signifie alors qu’il a bien transmis un nouvel enregistrement pour la zone inverse.

4.2. Sur le slave

Aug 15 21:05:56 dns2-test dhcpd: Added reverse map from 100.1.168.192.in-addr.arpa to xptest.opensharing.priv

 

5. Transfert de la zone inverse du DNS master vers le slave

Un nouvel enregistrement a été ajouté à la zone inverse sur le DNS master, il doit être transmis au DNS slave.
Pour cela, le master signifie une modification de la zone inverse au slave en lui envoyant une notification du serial de son SOA tout en s’authentifiant auprès du slave avec la clef TSIG.

5.1. Sur le master

Aug 15 21:05:56 dns1-test named[525]: zone 1.168.192.in-addr.arpa/IN/internal: sending notifies (serial 2016081448)

Le slave initie alors un transfert de la zone inverse.

5.2. Sur slave

Aug 15 21:05:56 dns2-test named[540]: client 192.168.1.11#10899/key tsig-key: view internal: received notify for zone '1.168.192.in-addr.arpa': TSIG 'tsig-key'
Aug 15 21:05:56 dns2-test named[540]: zone 1.168.192.in-addr.arpa/IN/internal: Transfer started.
Aug 15 21:05:56 dns2-test named[540]: transfer of '1.168.192.in-addr.arpa/IN/internal' from 192.168.1.11#53: connected using 192.168.1.12#36029
Aug 15 21:05:57 dns2-test named[540]: zone 1.168.192.in-addr.arpa/IN/internal: transferred serial 2016081448: TSIG 'tsig-key'
Aug 15 21:05:57 dns2-test named[540]: transfer of '1.168.192.in-addr.arpa/IN/internal' from 192.168.1.11#53: Transfer completed: 1 messages, 5 records, 322 bytes, 0.151 secs (2132 bytes/sec)

5.3. Au même moment sur le master

Aug 15 21:05:56 dns1-test named[525]: client 192.168.1.12#36029/key tsig-key (1.168.192.in-addr.arpa): view internal: transfer of '1.168.192.in-addr.arpa/IN': IXFR started: TSIG tsig-key
Aug 15 21:05:56 dns1-test named[525]: client 192.168.1.12#36029/key tsig-key (1.168.192.in-addr.arpa): view internal: transfer of '1.168.192.in-addr.arpa/IN': IXFR ended

 

Rmq : L’enregistrement de type DHCID (propre à la zone directe) correspond à des informations uniques propres au client envoyées par celui-ci, concaténées, puis hashées par un algorithme de type SHA256. Il a pour but d’éviter les doublons dans les enregistrements directs du DNS et ressemble à cela :

xptest.opensharing.priv. 240	IN	DHCID	AAEBXwtkUp+5xiKwiFAjBepXdr7D3zFaCOJ5cn2GydHDomo=

Le FQDN pointe sur une valeur en base 64 que l’on peut décoder avec Python :

>>> import base64
>>> base64.b64decode("AAEBXwtkUp+5xiKwiFAjBepXdr7D3zFaCOJ5cn2GydHDomo=")
'\x00\x01\x01_\x0bdR\x9f\xb9\xc6"\xb0\x88P#\x05\xeaWv\xbe\xc3\xdf1Z\x08\xe2yr}\x86\xc9\xd1\xc3\xa2j'

Le résultat est une chaine en base 16 (hexadécimal).
Elle correspond à la chaine relative au paramètre ddns-dhcid généré pour le bail, mais en base 8 (octal) :

set ddns-dhcid = "\000\001\001_\013dR\237\271\306\"\260\210P#\005\352Wv\276\303\3371Z\010\342yr}\206\311\321\303\242j";

5.4. Pour résumer

Informations d’identification reçues et données au client
-> hashage (SHA256)
-> conversion base 8 (ddns-dhcid)
-> conversion base 16
-> conversion base 64 (enregistrement DNS DHCID)

 

---

 

Analyse du failover

Imaginons que le serveur DHCP slave présente une défaillance, voici les phases que nous observerons sur les 2 serveurs :

1. Slave : Défaillance
   Master : communications-interrupted

   Aug 14 22:41:06 dns1-test dhcpd: failover peer opensharing-failover: I move from normal to communications-interrupted
   

 

2. Slave : Reprise du service : recover (reçoit la mise à jour de la base de données des baux du master : synchronisation)

   Aug 14 22:41:08 dns2-test dhcpd: failover peer opensharing-failover: I move from startup to recover
   Aug 14 22:41:08 dns2-test dhcpd: Sent update request all message to opensharing-failover
   Aug 14 22:41:23 dns2-test dhcpd: failover peer opensharing-failover: peer update completed
   

   Master : partner-down (partenaire inopérationnel temporairement, le master devra assurer le service seul)

   Aug 14 22:41:07 dns1-test dhcpd: failover peer opensharing-failover: I move from communications-interrupted to partner-down
   Aug 14 22:41:08 dns1-test dhcpd: Update request all from opensharing-failover: sending update
   Aug 14 22:41:23 dns1-test dhcpd: Sent update done message to opensharing-failover
   

 

3. Slave : recover-wait (restera dans cet état le temps défini par le paramètre mclt : phase de basculement)

   Aug 14 22:41:23 dns2-test dhcpd: failover peer opensharing-failover: I move from recover to recover-wait
   

   Master : partner-down

 

4. Slave : recover-done (phase très courte, annonce la fin de sa convalescence à son partenaire)

   Aug 14 22:49:06 dns2-test dhcpd: failover peer opensharing-failover: I move from recover-wait to recover-done
   

   Rmq : Ici, le mclt a été défini, pour les tests, à 8 min (480 sec)
   Master : partner-down

 

5. Slave : normal

   Aug 14 22:49:07 dns2-test dhcpd: failover peer opensharing-failover: I move from recover-done to normal
   Aug 14 22:49:07 dns2-test dhcpd: failover peer opensharing-failover: Both servers normal
   

   Master : normal

Aug 14 22:49:07 dns1-test dhcpd: failover peer opensharing-failover: I move from partner-down to normal

Les phases seraient les mêmes si le master présentait une défaillance.
Ces différentes étapes sont reportées chronologiquement dans le fichier des baux : /var/lib/dhcp/dhcpd.leases

Rmq : Si un client fait une requête DHCP pour obtenir une IP, on observera sur le serveur défaillant pendant la phase de besculement :

Aug 14 20:13:14 dns2-test dhcpd: DHCPDISCOVER from 00:11:43:a2:d7:aa via eth0: not responding (recover wait)

 

---

 

L’importance de la synchronisation de l’heure dans le failover

Si les deux serveurs DHCP ne sont pas synchronisés temporellement, ils n’arriveront pas à joindre le failover et aucun ne pourra servir les clients DHCP :

Aug 17 01:19:59 dns2-test dhcpd: Failover CONNECT from opensharing-failover: time offset too large
Aug 17 01:19:59 dns2-test dhcpd: failover: disconnect: time offset too large
Aug 17 01:19:59 dns2-test dhcpd: failover: link startup timeout

Aug 17 01:16:58 dns1-test dhcpd: Failover CONNECT to opensharing-failover rejected: Connection rejected, time mismatch too great.

Ici, les deux serveurs DHCP possèdent 3 minutes de décalage, ce dernier étant trop important pour se connecter au failover, que ce soit le master ou le slave.
 
Et lorsque les deux serveurs se resynchronisent, la jonction au failover se fait :

Aug 17 01:20:14 dns1-test dhcpd: failover peer opensharing-failover: peer moves from communications-interrupted to normal
Aug 17 01:20:14 dns1-test dhcpd: failover peer opensharing-failover: Both servers normal

 

---

 

Analyse du load-balancing

 

Le client fait une requête DHCP sur le failover (les 2 serveurs la reçoivent)
 
Sur le master :

Aug 15 11:41:20 dns1-test dhcpd: DHCPDISCOVER from 08:00:27:a8:cc:30 via eth0: load balance to peer opensharing-failover
Aug 15 11:41:21 dns1-test dhcpd: DHCPREQUEST for 192.168.1.102 (192.168.1.12) from 08:00:27:a8:cc:30 via eth0: lease owned by peer

Sur le slave :

Aug 15 11:41:20 dns2-test dhcpd: DHCPDISCOVER from 08:00:27:a8:cc:30 via eth0
Aug 15 11:41:21 dns2-test dhcpd: DHCPOFFER on 192.168.1.102 to 08:00:27:a8:cc:30 (debianmysql) via eth0
Aug 15 11:41:21 dns2-test dhcpd: DHCPREQUEST for 192.168.1.102 (192.168.1.12) from 08:00:27:a8:cc:30 (debianmysql) via eth0
Aug 15 11:41:21 dns2-test dhcpd: DHCPACK on 192.168.1.102 to 08:00:27:a8:cc:30 (debianmysql) via eth0

On voit ici que c’est le slave qui a la charge de l’attribution de la configuration réseau du client.
Le failover détermine quel serveur gérera ce nouveau client. Lors de l’initialisation du failover, la plage d’IP a été scindée en 2 (split 128).
En consultant le fichier des baux, /var/lib/dhcp/dhcpd.leases, on remarque deux types de baux potentiels :
Les adresses free, affectables par le serveur master :

lease 192.168.1.161 {
  binding state free;
}
lease 192.168.1.162 {
  binding state free;
}

Les adresses backup, affectables par le serveur slave :

lease 192.168.1.147 {
  starts epoch 1471262212; # Mon Aug 15 13:56:52 2016
  tstp epoch 1471262212; # Mon Aug 15 13:56:52 2016
  tsfp epoch 1471262212; # Mon Aug 15 13:56:52 2016
  atsfp epoch 1471262212; # Mon Aug 15 13:56:52 2016
  binding state backup;
}
lease 192.168.1.148 {
  starts epoch 1471262212; # Mon Aug 15 13:56:52 2016
  tstp epoch 1471262212; # Mon Aug 15 13:56:52 2016
  tsfp epoch 1471262212; # Mon Aug 15 13:56:52 2016
  atsfp epoch 1471262212; # Mon Aug 15 13:56:52 2016
  binding state backup;
}

Ici, le failover a divisé le pool 192.168.1.100-192.168.1.199 en 2 :

• 192.168.1.100-192.168.1.149 : 50 adresses utilisables par le slave
• 192.168.1.150-192.168.1.199 : 50 adresses utilisables par le master

Ce que confirment les logs sur les deux serveurs :

Aug 15 12:05:45 dns1-test dhcpd: balancing pool b7cac390 192.168.1.0/24  total 100  free 50  backup 50  lts 0  max-own (+/-)10
Aug 15 12:05:45 dns1-test dhcpd: balanced pool b7cac390 192.168.1.0/24  total 100  free 50  backup 50  lts 0  max-misbal 15

Aug 15 12:05:14 dns2-test dhcpd: balancing pool b7bb2350 192.168.1.0/24  total 100  free 50  backup 50  lts 0  max-own (+/-)10
Aug 15 12:05:14 dns2-test dhcpd: balanced pool b7bb2350 192.168.1.0/24  total 100  free 50  backup 50  lts 0  max-misbal 15

 

---

 

Aller encore plus loin

Pour continuer à explorer la configuration de ISC DHCP, voir les articles suivants :

• ISC DHCP – Configuration avancée
• ISC DHCP – Commandes utiles

 

Annexes

PAPLxx : fait référence à un sujet développé dans la section Pour aller plus loin

 

Références

• dhcpd.conf(5) – Linux man page
• dhcp-options(5) – Linux man page
• dhcpd-eval(5) – Linux man page
• dhcpd.leases(5) – Linux man page
• IETF – RFC2131 – Dynamic Host Configuration Protocol
• Internet Systems Consortium – ISC DCHP Homepage
• RHEL 7 – Networking Guide – Chapter 10 DHCP Servers
• Zytrax – DDNS with DHCPv4
• NLUG – NTPQ Command
• O’Reilly TCP/IP Network Administration – D.3. The dhcpd.conf Configuration File
• Command Center – HOWTO Design a fault-tolerant DHCP + DNS solution
• IT-Connect – Redondance de serveurs DHCP sous Linux
• Wiki Debian – DDNS