Saltar la navegación

Protocolo DHCP Failover

En redes grandes el servicio DHCP es un servicio crítico, por lo que sería deseable en estas redes que pudieran trabajar múltiples servidores DHCP proporcionándose así redundancia para el caso en el que falle uno de los servidores. El protocolo DHCP Failover suministra la sincronización entre dos servidores DHCP para que en caso de que falle uno de ellos, el otro permita que la asignación y renovación de IP siga produciéndose. Este protocolo permite que ambos servidores mantengan una base de datos de IP consistente.

El protocolo DHCP Failover también implementa un algoritmo para aportar balanceo en la asignación de IP entre los dos servidores.

El servidor DHCP de ISC puede configurarse para que pueda usar este protocolo y se sincronice con un segundo servidor DHCP, que se aconseja que sea también ISC y no de otro fabricante.

La configuración del protocolo DHCP Failover en el servidor de ISC comienza con la declaración failover peer en cada uno de los dos servidores, en la cual se especifican los parámetros de la relación y cómo contactar con el servidor compañero. Hecho esto, a continuación, en los dos servidores se debe asociar dicha declaración con el o los pools de direcciones IP que vayan a compartir. La sintaxis de la declaración failover peer es la siguiente:

failover peer "nombre" {
    estamentos;
}

El nombre especificado se utilizará para asociar dicha declaración a uno o varios pools concretos.

Los estamentos que podemos utilizar en la declaración anterior son los siguientes:

Estamento Significado
 primary; Especifica que el servidor actuará como primario. (Obligatorio)
 secondary; Especifica que el servidor actuará como secundario. No hay diferencia en cuanto al funcionamiento entre el primario y el secundario, pero si se configuran de forma levemente distinta. (Obligatorio)
 address dirección-IP; Especifica la dirección IP del servidor que se está definiendo. Puede ser una IP numérica o un nombre. (Obligatorio)
 port numero-puerto;
 Especifica el puerto por el que escuchará el servidor los mensajes de sincronización de su compañero. (Opcional, por defecto se asumiría el 647)
 peer address dirección-IP; Especifica la dirección IP del compañero. (Obligatorio)
 peer port numero-puerto; Especifica el puerto por el que escucha el compañero los mensajes del protocolo failover. (Opcional, por defecto se asumiría el 647)
 max-unacked-updates número; Especifica el número de mensajes de sincronización BNDUPD pueden ser enviados desde uno de los servidores sin recibir el mensaje de aceptación BNDACK del otro servidor. (Obligatorio)
 max-response-delay segundos; Especifica el número de segundos que el servidor debe esperar sin recibir mensajes para concluir que la conexión con su pareja se ha caído. Debe ser un tiempo razonable para que un corte accidental de pocos segundos no se interprete prematuramente como una caída de conexión, que posteriormente implicará la sincronización de ambos servidores. (Obligatorio)
 mclt segundos; Indica el tiempo máximo por el que uno de los servidores extiende las concesiones de IP del servidor caído. También es el tiempo que el servidor caído estará sin servir IP cuando se recupere, dando tiempo así a que caduquen las IP renovadas por el servidor que lo ha sustituido. Esta declaración es obligatoria y sólo se especifica en la configuración del maestro, que es quien se lo comunicará al esclavo. Las dos figuras que están a continuación de esta tabla, clarifican el funcionamiento de mclt y max-response-delay.
 split valor;

Sirve para indicar que habrá balanceo entre los dos servidores DHCP, es decir, el servidor primario y el secundario se repartirán el trabajo de asignación de IP.

Esta declaración sólo se especifica en el servidor maestro, y valor puede estar comprendido entre 0 y 255. 0 indica 0%, 128 indica 50% (es el valor usado más habitualmente) y 255 indica 100% lo que significaría que sólo el servidor primario asignará IP, y el secundario únicamente se utiliza como copia de seguridad que el primario irá actualizando. En este último caso, el secundario sólo se activaría cuando detecte que la conexión con el primario se ha caído. (Obligatorio)
 load balance max seconds segundos; El efecto de este parámetro se produce cuando uno de los servidores responde a los mensajes de sincronización (está por tanto activo) pero no responde a los mensajes de solicitud de IP de los clientes pues su parte del pool se ha agotado. Los clientes DHCP incluyen en la solicitud de IP el número de segundos que llevan haciendo dicha solicitud sin respuesta, y cuando estos segundos son iguales o superiores a los especificados en load balance max seconds entonces el otro servidor, que en principio no debería atender la petición pues está en el ámbito del compañero, sí la atiende y la hace suya.

DHCP Failover

  DHCP Failover

Ejemplo de dos servidores ISC DHCP compartiendo al 50% un mismo pool:

Configuración del servidor DHCP maestro:

authoritative;
ddns-update-style none;

failover peer "FAILOVER" {
  primary; 
  address 192.168.1.2;
  port 647;
  peer address 192.168.1.3;
  peer port 647;
  max-unacked-updates 10;
  max-response-delay 30;
  load balance max seconds 3;
  mclt 1800;
  split 128;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
  option broadcast-address 192.168.1.255;
  option routers 192.168.1.1;
  option domain-name-servers 8.8.8.8, 8.8.4.4;
  pool {
    failover peer "FAILOVER";
    max-lease-time 3600;
    range 192.168.1.50 192.168.1.199;
  }
}

Configuración del servidor DHCP secundario:

authoritative;
ddns-update-style none;

failover peer "FAILOVER" {
  secondary;
  address 192.168.1.3;
  port 647;
  peer address 192.168.1.2;
  peer port 647;
  max-unacked-updates 10;
  max-response-delay 30;
  load balance max seconds 3;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
  option broadcast-address 192.168.1.255;
  option routers 192.168.1.1;
  option domain-name-servers 8.8.8.8, 8.8.4.4;
  pool {
    failover peer "FAILOVER";
    max-lease-time 3600;
    range 192.168.1.50 192.168.1.199;
  }
}