a

1. 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

2. Cuando configuramos a una máquina para que obtenga configuración IPv4 automáticamente, ésta incializa 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”

3. 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”

4. 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”

5. 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

6. 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

7. 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

8. 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

9. 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

11. 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