Cómo Funciona el Servicio DHCP (Incluye Capturas de Red)

Como hace tiempo estoy observando muchas preguntas y búsquedas sobre el servicio
DHCP, en esta nota haré una descripción del objetivo y funcionalidad del mismo, la
configuración básica, y analizaremos la información que se transmite en la red
correspondiente a este servicio

Como primer punto, es importante conocer cuál es la funcionalidad que provee el

servicio DHCP. El objetivo del servicio DHCP es automatizar la configuración IP de un
grupo de máquinas

Cuando se disponen máquinas en una red con protocolo TCP/IP, como todos
sabemos, es necesario configurarle parámetros adecuados, obligatoriamente
Dirección IP y Máscara de Subred, y seguramente algunos más como son la Puerta de
Enlace (Default Gateway), dirección de servidores DNS y/o WINS, sufijo de dominio,
etc.

Lo anterior lo podemos hacer manualmente máquina por máquina, si son pocas puede
ser una opción, pero a medida que aumenta la cantidad de equipos, o que cambien
parámetros, o inclusive si disponemos de más de una red, el tema se va tornando más
complicado, pues además de tener que cambiar la configuración en cada máquina
debemos llevar el control de que no se repitan las direcciones IP, o marcarlas cuándo
se dejan de usar

Justamente para evitar ese trabajo, es que usamos el servicio DHCP

Aunque este servicio es habitual que funcione en Routers (Enrutadores), en este

ejemplo desarrollaré el tema sobre el servicio DHCP en un sistema servidor. El
funcionamiento es el mismo

El servicio DHCP se debe instalar sobre un sistema operativo de tipo servidor, que
tenga configurados parámetros de IP en forma manual, no automática. Esto es
importante porque un “Servidor DHCP” no puede ser al mismo tiempo “Cliente DHCP”

Una vez instalado el servicio hay que configurar un Ámbito, o sea un rango de
direcciones IP que “alquilará” temporalmente a los clientes que lo soliciten. Este mismo
Ámbito lo podemos configurar para que conjuntamente con Dirección IP y Máscara de
Subred (los dos obligatorios) además configure otros parámetros adicionales que
necesitemos, como ser Puerte de Enlace (Default Gateway), servidores DNS, etc.

Una vez que tenemos el ámbito creado y configurado ya tenemos el servicio disponible
para ser usado

¿Y cómo acceden y configuran los clientes para usar este servicio? es lo más fácil que
hay, ya que por omisión las máquinas Windows quedan en su configuración IP para
obtener una dirección IP y DNS en forma automática. Eso es todo

Una muy breve descripción de los diferentes tráficos de red para poder comprender lo
que sigue

En una red TCP/IPv4 existe tres tipos de tráfico:

 Unicast: tráfico de uno a uno

  Broadcast: tráfico de uno a todos
 Multicast: tráfico de uno a un grupo determinado, no todos

Aclarado lo anterior comencemos con el tema que nos ocupa

Cuando configuramos a una máquina para que obtenga configuración IPv4

automáticamente, ésta inicializa una versión reducida del protocolo TCP/IPv4 la cual
permite enviar tráfico desde la dirección IP 0.0.0.0 (undefined = no definida) hacia
255.255.255.255 (la dirección IPv4 de Broadcast); además le permite recibir tráfico de
Broadcast (255.255.255.255)

Entonces el primer paso que debe hacer el cliente es averiguar si hay algún servidor
DHCP que le pueda asignar su configuración. Para esto envía un Broadcast llamado
“DHCP Discover”, usando como dirección de origen 0.0.0.0 y como destino
255.255.255.255

Todos los servidores DHCP, porque en algunas circunstancias podría haber más de
uno, que escuchen este pedido, y que dispongan de una dirección IPv4 libre y válida
como para ofrecer lo harán. Elegirán una dirección IP de su ámbito, la marcarán como
ofrecida, y se la harán llegar al cliente a traves de un Broadcast llamado “DHCP Offer”
usando como dirección de origen la dirección del servidor DHCP, y como origen
255.255.255.255 que es lo único que puede recibir el cliente

Si el cliente recibiera más de un ofrecimiento de DHCP, aceptará el primero que

reciba, y este es uno de los motivos por los que no hay balance de carga por parte del
cliente entre varios servidores DHCP

Luego que el cliente acepta el ofrecimiento, se lo hará saber a los servidores DHCP
que le han ofrecido configuración enviando un Broadcast llamado “DHCP Request”
que incluye la dirección IP del server del cual aceptó el ofrecimiento. Todavía sigue
usando como origen 0.0.0.0 ya que aún no ha finalizado el proceso

Los servidores DHCP que reciban este tráfico del cliente y que no les fue aceptado el
ofrecimiento, vuelven a marcar la dirección ofrecida como libre; pero en cambio el
servidor al cual se le aceptó el procedimiento (indicado en el “DHCP Request”)
marcará la dirección como ocupada, y se la confirmará al cliente con un Broadcast
llamado “DHCP Ack”

Recién cuando el cliente reciba este cuarto mensaje (“DHCP Ack”) terminará de
incializar TCP/IPv4 y comenzará a usar los parámetros asignados, incluyendo la
dirección IP

Resumiendo, hay cuatro mensajes de tipo Broadcast durante la obtención de una

dirección IPv4, a través de DHCP

 DHCP Discover (Broadcast de cliente a servidores)

 DHCP Offer (Broadcast de servidores a cliente)
 DHCP Request (Broadcast de cliente a servidores)
 DHCP Ack (Broadcast de servidor DHCP a cliente)

Para completar la información, la configuración que ofrece el servidor DHCP a los

clientes tiene un período de validez que el cliente deberá renovar periódicamente, por
eso se habla de una “alquiler” o “lease”
Si la máquina cliente quedara prendida la renovación del “lease” se hará llegado el
50% del tiempo de asinación.
Si la máquina cliente se apagara o reiniciar, se renovará en cada arranque

Hay una diferencia en el tráfico de acuerdo al primer o el segundo caso. En el primero,

como el cliente tiene dirección IP y conoce que aún tiene tiempo el tráfico es dirigido
entre cliente y servidor, y es con los dos últimos de los cuatro mencionados
anteriormente, esto es “DHCP Request” y “DHCP Ack”

En el segundo caso, también son los mismos mensajes, pero en este caso el tráfico es
por Broadcast, esto tiene por finalidad conocer si el cliente fue cambiado de red, ya
que en ese caso no llegaría el Broadcast al servidor y no podría renovar el “lease”, lo
cual es lógico pues al cambiar de red necesita otra configuración diferente de IP

Muy bien, hasta ahora hemos visto muy buena teoría pero ¿será realmente así el
tráfico de red? :-)

Para mostrar que realmente el tráfico es así, me valdre de una instalación con dos
máquinas: un Controlador de Dominio (DC1) que uso para todas las demostraciones,
aunque no es un requerimiento, donde he instalado el servicio DHCP y le he
configurado el ámbito 192.168.1.20 a 192.168.1.20 a 192.168.1.50/24, con parámetros
adicionales Puerta de Enlace, servidor DNS y sufijo de dominio. Como cliente he
usado otra máquina SRV1, no necesario pero es parte del Dominio

Para poder mostrar el tráfico de red, en DC1 he instalado un “Analizador de Protocolo”,

conocidos como “Sniffers”, que puede ser cualquiera pero por facilidad y
compatibilidad he descarga e instalado Netowrk Monitor de Microsoft que es gratuito y
puede descargarse fácilmente desde Microsoft Downloads y por supuesto ya lo he
instalado

Para el que no esté familiarizado con este tipo de aplicaciones, en la parte superior se
muestra el paquete de red, y en la parte inferior el contenido del mismo agrupado por
encapsulado. Por temas de espacio muesto sólo los más interesantes que prueban lo
comentado al principio de la nota, y he resaltado en color amarillo los datos
importantes

En la siguiente figura vemos el “DHCP Request”

Como podemos observar, a nivel MAC es un Broadcast que va desde la dirección
MAC de la placa de red (VMware) a la dirección de Broadcast (FF-FF-FF-FF-FF-FF)
En cuyo interior va protocolo IP con origen en 0.0.0.0 destinado a 255.255.255.255
(Broadcast)
Como DHCP utiliza protocolo UDP va desde el puerto UDP-68 (Cliente), a puerto
UDP-67 (Servidor)
E informa que se trata de un “DHCP Request”

A continuación la respuesta del servidor DHCP, el “DHCP Offer”

Donde vemos que va desde DC1 (el servidor DHCP) a 255.255.255.255 (Broadcast) y
que se trata de un “DHCP Offer” que le está ofreciendo al cliente la dirección IP
192.168.1.20/24
En la parte inferior se llega a ver los tiempos de “lease” y renovación, y parámetros
adicionales (Domain Name, Router, etc.)

En tercer lugar, es el “DHCP Request” del cliente

Que también es un Broadcast desde 0.0.0.0 a 255.255.255.255, donde informa que
acepta la dirección IP 192.168.1.20 ofrecida por el DHCP 192.168.1.201

Y por último el cuarto mensaje “DHCP Ack”, también Broadcast

En este último el servidor DHCP le confirma (Ack = Acknowledge) que le ha asignado
la dirección IP 192.168.1.20/24 y reconfirmando los tiempos de “lease” y en qué
períodos debe hacer la renovación, y los parámetros adicionales

Por último, veamos cómo son las renovaciones. Primero en caso de reinicio del cliente
donde podremos observar que la renovación son “DHCP Request” y “DHCP Ack” en
forma de Broadcast como era lo esperado
Observen que el ciente indica un “RequestedIPAddress” o sea que solicita que de ser
posible le mantenga la misma dirección IP que tenía anteriormente

Y seguidamente el servidor le responde con el “DHCP Ack” renovandole la dirección y

reconfirmando los demás parámetros
Si en lugar de reinciar el cliente, la renovación fuera porque permaneció más del
“RenewTimeValew” (50% del “lease”), la renovación se efectuará por Unicast
En mi caso he ejecutado el comando IPCONFIG /RENEW para no estar esperando
cuatro días :-)
Podemos ver que como importante sólo ha cambiado el tipo de tráfico, el resto es igual
Esperemos que este artículo contribuya a comprender mejor cómo funciona el servicio
DHCP, confirmarlo a través de un Analizador de Protocolo, y además alentar a que
investiguen cómo funciona una red viendo y analizando lo que circula por el cable.
Esto último no es fácil pero cuando los problemas son de difícil solución un Analizador
de Protocolo ayuda muchísimo