# [DHCP] Priorizar dos servidores (Solucionado).

## Coghan

Ejemplos: 

Una LAN casera o LAN pyme con nuestro servidor Gentoo y un router ADSL, ambos con el servidor DHCP habilitado.

Un balanceador de un cluster HA y varios servidores con DHCP habilitado.

Cuando tienes varios servidores en el mismo segmento de red solemos configurarlo para que suministren rangos IP diferentes para que no se pisen unos a otros. Hasta aquí todo correcto, pero ¿existe alguna manera de priorizar un servidor frente a otro?.

Me interesa en el primer ejemplo que el DHCPD de mi Gentoo sea el primario y todas las solicitudes sean atendidas por éste, pero en caso de que no esté en línea, el router ADSL sea el que las atienda. En el segundo ejemplo para poder seguir un orden de peticiones.

¿Alguien conoce el protocolo a fondo como para sacarme de esta duda?, ni que decir que ya he mirado por el submundo sin encontrar como hacerlo.

----------

## sag

En DHCP client puedes decir de que Server DHCP tiene que coger la ip.

```
option dhcp-server-identifier ip-address 
```

Lo de que no se es como hacer uno maestro y otro esclavo, poque curiosamente coge la ip del que primero responde,

lo único que se me ocurre es que le metas mas retardo de respuesta en el segundo DHCP así solo cogerá la ip del primero que responde que sera el maestro, prueba algo de esto.

Bueno espero que esto te sirva.

----------

## Coghan

sag, Gracias por tu respuesta:

En el cliente no me interesa tocar nada porque quiero que pueda solicitar al dhcpd esclavo cuando el maestro no esté en línea.

Lo que comentas del tiempo de respuesta lo miraré, pero en el primer ejemplo los dhcp de los router ADSL no son configurables a ese nivel, así que tendré que probar el camino contrario, bajar la respuesta del maestro lo suficiente como para que el esclavo no atienda primero, tendré que hacer muchas pruebas.

Por otro lado he encontrado esta configuración para balanceo de dhcp con dns dinámica:

http://www.linuxhelp.net/forums/Dhcp_dynamicdnsfailover_t6037.html

Veo que hay detalles que me interesan, los voy a estudiar y veré que saco.

----------

## Inodoro_Pereyra

A menos que esté dentro de tus posibilidades y se justifique algún tipo de heartbeat entre tus servidores dhcp de forma de que siempre haya uno solo corriendo en la la red y no todos en simultáneo, lo que te comenta sag mas arriba es la única opción viable. Por otro lado no se me ocurre como se podría implementar semejante cosa...  :Very Happy: 

Ahora que lo pienso, ettercap en uno de sus tantos ataques man-in-the-middle puede ganarle la carrera a cualquier servidor dhcp, voy a ver si averiguo como lo hace por que por ahí deben venir los tiros...

Sumamente productivo mi aporte hoy.

Salud!

----------

## Coghan

 *Inodoro_Pereyra wrote:*   

> A menos que esté dentro de tus posibilidades y se justifique algún tipo de heartbeat entre tus servidores dhcp de forma de que siempre haya uno solo corriendo en la la red y no todos en simultáneo, lo que te comenta sag mas arriba es la única opción viable. Por otro lado no se me ocurre como se podría implementar semejante cosa... 

 

Efectivamente, ya había implementado una red con heartbeat en un cluster HA, con algunos servicios en activo/pasivo y otros balanceados. Precisamente el dhcp lo tengo balanceado, los servicios que no pude balancear son los que tengo como activo/pasivo.

 *Quote:*   

> Ahora que lo pienso, ettercap en uno de sus tantos ataques man-in-the-middle puede ganarle la carrera a cualquier servidor dhcp, voy a ver si averiguo como lo hace por que por ahí deben venir los tiros...

 

Espero con impaciencia tus investigaciones.

 *Quote:*   

> Sumamente productivo mi aporte hoy.

   :Very Happy: 

----------

## Coghan

Ahora que lo pienso, priorizar por la cara (o por la fuerza) nuestro dhcp en una red debería estar considerado como un ataque a la red, y si esto fuera posible sería un fallo grave, vulnerando la integridad de la red, ya que un atacante podría colocar su propio dhcp server aceptando peticiones antes que cualquier otro y haciendo lo que le venga en gana con los clientes que asigna.

----------

## sag

¿Estas seguro que no se puede reconfigurar el router?

Entrando por telnet al router , a veces te sorprendes de la cosas que puede hacer, como en mi caso, me paso con un con un D-Link, que al final era un linux con busybox.

----------

## Coghan

 *sag wrote:*   

> ¿Estas seguro que no se puede reconfigurar el router?
> 
> Entrando por telnet al router , a veces te sorprendes de la cosas que puede hacer, como en mi caso, me paso con un con un D-Link, que al final era un linux con busybox.

 

En mi caso es un router adsl Comtrend de Teléfonica, he accedido por telnet y las opciones que me muestra son estas:

```
> dhcpserver --help

Usage: dhcpserver config <start IP address> <end IP address> <leased time (hour)>

       dhcpserver relay <DHCP Server Relay IP address>

       dhcpserver leasetable

       dhcpserver show

       dhcpserver --help
```

la única diferencia con el interfaz html es la opción relay, me he puesto a jugar con ella y le he asignado la ip del dns de mi Gentoo para ver si de esta manera rechaza las peticiones en favor del servidor maestro. El caso es que funciona, desde el portátil he reiniciado el servicio net.eth0 y este es el resultado con los dos servidores dhcp activos:

 *Quote:*   

> eth0: carrier acquired
> 
> eth0: broadcasting for a lease
> 
> eth0: offered 192.168.1.6 from 192.168.1.2
> ...

 

Nos fijamos en la línea que he marcado en negrita cómo ignora la oferta del router ADSL y se queda con la del servidor Gentoo.

He realizado los test con todas las combinaciones que se me ocurrieron, incluso reinicié el servicio net.eth0 20 veces para ver si por aleatoriedad cambiaba algo, el resultado ha sido satisfactorio. Al parar el servicio dhcp de mi Gentoo el route vuelve a asignar correctamente, he vuelto sobre la marcha a iniciar el servicio en Gentoo y éste es el que manda.

Con respecto al segundo ejemplo de arriba, el balanceador, me quedo con las opciones mclt y split, aún no las he probado pero parece ser la cuestión para hacer que el servidor maestro controle al esclavo:

 *man dhcpd.conf wrote:*   

> The mclt statement 
> 
>  mclt seconds; 
> 
>  The mclt statement defines the Maximum Client Lead Time. It must be specified on the primary, and may not be specified on the secondary. This is the length of time for which a lease may be renewed by either failover peer without contacting the other. The longer you set this, the longer it will take for the running server to recover IP addresses after moving into PARTNER-DOWN state. The shorter you set it, the more load your servers will experience when they are not communicating. A value of something like 3600 is probably reasonable, but again bear in mind that we have no real operational experience with this. 
> ...

 

----------

## Inodoro_Pereyra

A ver si entiendo: Tu cliente dhcp prefiere y prioriza al servidor que le ofrece los DNS en la misma subred? Sería un comportamiento de lo mas lógico pensandolo bien... Con clientes corriendo windows pasa lo mismo?

Salud!

----------

## Coghan

 *Inodoro_Pereyra wrote:*   

> A ver si entiendo: Tu cliente dhcp prefiere y prioriza al servidor que le ofrece los DNS en la misma subred?

 

No comprendo bien tu pregunta, ¿que tienen que ver los DNS en este caso?, aún así los dos servidores suministran las mismas direcciones DNS.

 *Quote:*   

> Con clientes corriendo windows pasa lo mismo?

 

¡Vaya!, ahora tendré que instalar un cuasisistema desos para poder finalizar los test. Pues vamos a tener que esperar a que me aparezca un equipo con windows, porque no pienso ponerme a instalar uno. Las pruebas la he hecho en casa, si en el curro tengo tiempo me pongo a ello.

----------

## Inodoro_Pereyra

He entendido mal entonces, me interesa el caso por que tengo un problema parecido en donde hay dos servidores dhcp y necesito que uno gane la carrera siempre que se pueda.

Lo que hiciste entonces fué decirle al dhcp server del router que haga de relay del dhcp server de tu pc que corre Gentoo? Voy a tener que leer un poco mas sobre las especificaciones del protocolo por que sigo sin entender como es que funciona  :Very Happy: 

Salud!

----------

## Coghan

 *Inodoro_Pereyra wrote:*   

> Lo que hiciste entonces fué decirle al dhcp server del router que haga de relay del dhcp server de tu pc que corre Gentoo? Voy a tener que leer un poco mas sobre las especificaciones del protocolo por que sigo sin entender como es que funciona 

 

Así es, pero sólo lo hice para probar porqué era la única opción que el router ADSL me dejaba tocar. Tampoco entiendo mucho porqué funciona, lo que deduzco es que la opción relay (relé) (siempre he pensado que se usaba para comunicar con otros servidores DHCP fuera del segmento de red actual), pasa las peticiones al otro servidor y en caso de que este no responda él mismo, que hace de relé, envía al cliente su opción y le dice al cliente (de alguna manera) que espere al servidor externo a que responda a la petición y en caso de no haber respuesta (timeout) elija la suya. Todo esto son conjeturas mías en base a las pruebas caseras que he realizado.

En mi caso que el servidor externo también está en la misma red, pueden pasar dos cosas:

Que primero responda el router ADSL haciendo de relay y le envíe la petición al servidor maestro.

Que primero responda el servidor maestro.

En ambos casos el resultado final es el deseado y con eso me conformo. Aunque estaría bien contrastar todo esto con documentación oficial, si encuentro algo lo postearé.

----------

## Coghan

Bueno, estaba algo equivocado pero no muy desencaminado.

Valga este documento como fiable para este caso:

http://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/doc-curso-salamanca-redes/redes-html/ch01.html#id2514115

Y este otro como manual interesante:

http://cfievalladolid2.net/tecno/linux/dhcp_dns.html

 *http://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/doc-curso-salamanca-redes/redes-html/ch01.html#id25141152 wrote:*   

> En un segmento Ethernet puede haber más de un servidor DHCPD; el cliente envía usando broadcast un mensaje DHCPDISCOVER (puede indicar en él la IP que le gustaría tener y durante cuánto tiempo) al que responden con un mensaje DHCPOFFER los servidores presentes; en ese mensaje ya va la IP que le ofrecen y los datos de configuración. El cliente escoge el servidor que quiere utilizar enviando una petición DHCPREQUEST que incluye el identificador del servidor; esta petición también es broadcast, para que sepan el resto de servidores que su ofrecimiento se ha rechazado. En la petición además se pueden solicitar datos de configuración adicionales. Si el servidor acepta la petición del cliente responde con DHCPPACK (dónde irá configuración adicional si la solicitó el cliente), o DHCPNAK si la rechaza, debido por ejemplo a que la IP ya está asignada; a priori no tiene mucho sentido que un servidor rechace la petición del cliente cuando son los datos que le acaba de ofrecer, pero en realidad un cliente puede hacer una petición DHCPREQUEST sin acabar de recibir un DHCPOFFER; por ejemplo una vez que ya se tiene una IP para renovar el "alquiler" se pide directamente la IP al servidor DHCPD que nos la dio sin necesidad de hacer DHCPDISCOVER.
> 
> Finalmente, el cliente tiene la opción de rechazar el mensaje DHCPPACK. Así mismo el cliente también tiene la opción de liberar la IP que se le ha asignado, con DHCPRELEASE.

 

De este párrafo explicándonos como se comunican realmente cliente y servidor, nos quedamos con la parte marcada en negrita, el cliente al final es el que elige.

 *http://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/doc-curso-salamanca-redes/redes-html/ch01.html#id2514115 wrote:*   

> En las peticiones DHCP es muy importante el uso del broadcast. Para permitir que funcione el DHCP sin necesidad de poner un servidor en cada subred se usan BOOTP/DHCP relay agents, que se encargan de reencaminar estas peticiones. 

 

 *http://cfievalladolid2.net/tecno/linux/dhcp_dns.html wrote:*   

> El agente Relay de DHCP (dhcrelay) permite realizar peticiones DHCP y BOOTP de una subred que no tiene servidor DHCP propio. Este agente pasa peticiones a otras subredes que si tienen servidores DHCP. Cuando un cliente solicita información, el agente pasa la petición a la lista de servidores especificada al iniciar el agente relay. Cuando un servidor devuelve la respuesta, la respuesta se devuelve al cliente que la solicitó. El agente relay debe tener tantas interfaces de red como a redes esté conectado y en principio escucha sobre todas ellas a no ser que se edite el fichero /etc/sysconfig/dhcrelay y se modifique la variable INTERFACES y se coloque la interfaz que interese. Además se deberá escribir la variable DHCPSERVERS=”listaServidores” 

 

Con lo cual un servidor relay solo se encarga de redirigir las peticiones al servidor y devolverlas al cliente, y como yo creía se usa para dar servicio DHCP a distintas subredes.

Con lo cual lo que he hecho ha sido un pequeño truco de magia, el router ADSL se comporta como relay mientras mi servidor maestro esté activo, como el router ADSL también es capaz de suministras pues lo hace sin más aunque e servidor maestro también suministre una, pero el cliente elegirá la que es suministrada por el agente relay el todos los casos, si el agente relay responde con la petición del servidor maestro, el cliente ignorará la otra como realmente ha pasado en mis pruebas. Y en caso de que el servidor maestro esté caído el realy no suministra datos o datos nulos y al cliente no le queda más remedio que escoger la ip que el router ADSL le suministra él mismo.

Espero no errar, si alguien conoce mejor el tema ya sabe donde justificarlo.  :Wink: 

----------

## Inodoro_Pereyra

Espectacular, mas claro imposible.

Ahora se mas o menos como tratar de resolver mi caso, espero que windows también siga los estándares, cosa que no acostumbra, a ver si consigo servir direcciones de IP con el servicio dhcp nativo de windows server a una red llena de clientes windows en donde en caso de falla (y falla seguido) se sirva dhcp desde el router adsl...

Gracias por tomarte la molestia de apuntarme los URLs.

Salud!

----------

## Coghan

Sr. Inodoro_Pereyra, es todo un placer poder serle útil.   :Wink: 

Se trata de ir aprendiendo, yo el primero.

----------

## Coghan

 *Inodoro_Pereyra wrote:*   

> Con clientes corriendo windows pasa lo mismo?

 

Como me ha venido una liz divina y me he puesto a jugar con kvm en casa, me acordé de esta pregunta y me puse a ello, instalé bajo kvm un 2003 server y me puse a probar el invento con el dhcp. Los resultados:

De entrada la ip la asignó correctamente el servidor dhcp maestro.

Haciendo desde linea de comandos un ipconfig /release y luego un /renew todo correcto, lo he hecho como 50 veces de manera aleatoria.

Cuando expira el tiempo asignado renueva correctamente con la misma ip.

Si utilizo la opción gráfica de windows "Reparar", todo se va al garete, hace lo que le viene en gana, elige un servidor u otro según Bill Gates haya desayunado.

Deshabilitando y volviendo a habilitar el dispositivo de red desde el administrado de dispositivos, recoge una ip desde el servidor maestro.

Desactivando y volviendo a activar la "Conexión de área local" desde el panel de control --> Conexiones de red, recoge ip correctamente.

Conclusión: con Windows no me fío un pelo. Bajo estas pruebas mientras no te de por usar la opción reparar del interfaz gráfico, parece, que te irá bien.

----------

