Protocolo de Configuración Dinámica de Host

(DHCP)

Jhonnier David Coronado Jenifer Medina Yepez Juan Sebastian Santamaria

Departamento de Ingeniería de Palomino
Vanegas
Sistemas Departamento de Ingeniería de
Departamento de Ingeniería de Pontificia Universidad Sistemas
Sistemas Javeriana Pontificia Universidad
Pontificia Universidad Bogotá D.C., Colombia. Javeriana
Javeriana jenifer.medina@javeriana.edu. Bogotá D.C., Colombia
Bogotá D.C., Colombia co juansantamaria@javeriana.edu.
jhonnier.coronado@javeriana.e
co
du.co
Configuración del router(Cisco) como relay agent para
Abstract—.This document will present the network el servidor DHCP con dirección IP 192.168.10.66:
protocol named Dynamic Host Configuration Protocol
R1> enable
(DHCP) defined by RFC 2131 of the IETF which has been
positioned as standard to dyamic automatic IP assignation R1# configure terminal
due to the possibility of dynamically configuring the network R1(config)# interface
configuration parameter, what is vital for the scalability of GigabitEthernet0/0
the networks. The document will cover the implementation
of DHCP protocol in the programming language. R1(config-if)# ip helper-address
Keywords—mensaje; DHCP; IP; mensaje; cliente; red 192.168.10.66

I. INTRODUCCIÓN
DHCP o Dynamic Host Configuration Protocol, fue
publicado en Octubre de 1993, un protocolo de red de tipo
cliente/servidor que permite que equipos conectados a una
red obtengan su configuración de red (direcciones IP,
dirección de servidor DNS, gateway, máscara de red, etc)
de manera dinámica. DHCP asigna dinámicamente los
parámetros de configuración de red a los dispositivos para
que puedan comunicarse con otras redes Inicialmente el
protocolo DHCP fue diseñado como un complemento del
protocolo BOOTP (Protocolo Bootstrap) por lo que
DHCP puede devolver parámetros BOOTP.
Este documento abarca la implementación en Java del
servidor DHCP, el cual contiene funciones de asignación, Figura 1. Topología de red.
liberación, renovación y revocación, además, acepta La topología de red utilizada para las pruebas del
solicitudes de múltiples sistemas operativos y permite una servidor está compuesta por dos subredes LAN y una red
visualización en tiempo real de la información. WAN. Las subredes LAN están conectadas mediante
II. TOPOLOGÍA Switches que a su vez están conectados a routers que
Un Agente Relay DHCP es un equipo que está conectan la red WAN.
configurado para escuchar mensajes broadcast de clientes
DHCP y reenviarlos al servidor DHCP en varias subredes,
Red 192.168.10.0/24.
por lo que se hace necesario configurar los routers como
agentes relay, para el efectivo funcionamiento del servidor
DHCP en múltiples subredes. LAN 1 192.168.10.0

Con el uso de Agentes Relay si el mensaje fue recibido Máscara de Red 255.255.255.192/26
de una subred distinta a la del servidor se enviará como
mensaje unicast hacia la dirección del gateway del agente Dirección Primer Host 192.168.10.2
relay al puerto 67 de UDP, si el mensaje fue recibido de la
Dirección Ultimo Host 192.168.10.62
misma subred del servidor se enviará un mensaje
broadcast al puerto 68 de UDP.
Dirección Gateway 192.168.10.1
 IP Servidor DHCP
Dirección Broadcast 192.168.10.63
IP del servidor DNS
Máscara de subred
LAN 2 192.168.10.64
Gateway
Tiempo de Arrendamiento
Máscara de Red 255.255.255.224/27 Tiempo de Renovación
…
Dirección Primer Host 192.168.10.66

Dirección Ultimo Host 192.168.10.94

Dirección Gateway 192.168.10.65

Dirección Broadcast 192.168.10.95

Red WAN 192.168.10.96

Máscara de Red 255.255.255.252/30

Dirección Primer Host 192.168.10.97

Dirección Ultimo Host 192.168.10.98

Dirección Broadcast 192.168.10.99

Tabla 1. Direccionamiento IP de la red 192.168.10.0/24.

III. DESCRIPCIÓN PROGRAMA

Figura 2. Formato de un mensaje DHCP [1].

Para el direccionamiento usado, se hizo uso del primer
host de la Red LAN 2 como IP asignada para el servidor
DHCP. Esta asignación junto con el resto de la
configuración del servidor se hace a través de la lectura de
un archivo de texto, el cual está estructurado de la
siguiente manera:
IP Inicial
IP Final
 Figura 3. Formato del archivo de configuración inicial

El servidor DHCP está configurado y montado de la

manera más automática posible, evitando así que tanto el
administrador como los hosts que hagan uso del mismo
puedan modificar parámetros de configuración y/o el uso
de las IPs del mismo, al momento de estar ejecutándose.
Aunque, se debe decir que, al la configuración ser cargada
mediante un archivo, este puede ser modificado por el
administrador, cambiando así la configuración del
servidor.
Al momento de iniciar la aplicación, el servidor abre un
socket en el puerto 67 de UDP, especificado en el RFC
1340.
Cada vez que se recibe un mensaje a través del
SOCKET, se pasa a una clase llamada MensajeDHCP para
facilitar el manejo de la información. El servidor analizará
el mensaje y dependiendo de sus características y el fin del
mismo, se procederá de un cierto modo específico.
Cada vez que el servidor de forma dinámica asigna una
IP a cualquier host que la solicite, se activa un timer (cuyo
valor fue leído anteriormente en el archivo de
configuración) , el cual corresponde al tiempo de
arrendamiento este host con la IP. Por cada mensaje que
llega, se informará los datos del remitente y del mensaje,
siendo estos escritos en un archivo de text. El servidor
finaliza sólo cuando se cierra la aplicación.
Existen dos posibles escenarios que ocurren durante la
implementación del servidor:
1. Discover->Offer->Request->Ack/Nak
2. Request->Ack/Nak

IV. PRUEBAS DEL SERVIDOR

La interfaz que maneja el administrador muestra
información que se va recopilando durante la ejecución
del servidor.

Figura 3. Interfaz administrador

Para las pruebas del servidor se utilizaron
ocho escenario distintos:

a) Primer escenario: en este escenario el cliente se

encuentra dentro de la misma subred (subred
192.168.10.65). El servidor recibe el DHCP
DISCOVER el cual fue enviado por el cliente,
luego se envía el DHCP OFFER, se recibe el
DHCP REQUEST y se procede a enviar el
DHCP ACK.

Figura 4. Screenshot prueba 1

Figura 5. Funcionamiento del programa

b) Segundo escenario: en este escenario se

encuentran dos clientes ubicados en la misma
subred (192.168.10.65). El servidor recibe el
DHCP DISCOVER el cual fue enviado por el
cliente, luego se envía el DHCP OFFER, se
recibe el DHCP REQUEST y se procede a enviar
el DHCP ACK.
 Figura 6. Screenshots prueba 2

c) Tercer escenario: en este escenario el cliente se

encuentra fuera de la subred del servidor, el
cliente está ubicado en la subred 192.168.10.1. El
servidor recibe el DHCP DISCOVER el cual fue
enviado por el cliente, luego se envía el DHCP
OFFER, se recibe el DHCP REQUEST y se
procede a enviar el DHCP ACK.

Figura 7. Screenshot prueba 3

d) Cuarto escenario: en este escenario hay dos
clientes fuera de la subred del servidor, los
clientes se encuentran ubicados en la subred
192.168.10.1. El servidor recibe el DHCP
DISCOVER el cual fue enviado por el cliente,
luego se envía el DHCP OFFER, se recibe el
DHCP REQUEST y se procede a enviar el
DHCP ACK.
 Figura 8. Screenshots prueba 4

e) Quinto escenario: en este escenario se hace la prueba de

renovación con un cliente fuera de la subred del
servidor, el cliente está ubicado en la subred
192.168.10.1.El servidor recibe el DHCP DISCOVER
el cual fue enviado por el cliente, luego se envía el
DHCP OFFER, se recibe el DHCP REQUEST y se
procede a enviar el DHCP ACK. Se hace uso de un
timer para el manejo del tiempo.

Figura 9. Screenshot prueba 5

f) Sexto escenario: en este escenario se hace la prueba de

error, el cliente rompe conexión con el servidor El
servidor recibe el DHCP DISCOVER el cual fue
enviado por el cliente, luego se envía el DHCP OFFER,
se recibe el DHCP REQUEST y se procede a enviar el
DHCP ACK. Tras la pérdida de conexión, el cliente
queda en un bucle enviando mensajes DHCP
REQUEST, el servidor debido a que no recibe mensajes
libera las ips luego que el tiempo de arrendamiento haya
transcurrido y no las renueva.
 Figura 10. Screenshot prueba 6

Figura 11. Screenshot Wireshark prueba 6

g) Séptimo escenario: en este escenario se hace la prueba

de revocación, para esta funcionalidad se recibe la IP a
liberar, se recorre la lista que contiene las direcciones de
arrendamiento y se elimina de la lista la IP.

Figura 12. Screenshot Wireshark prueba 7

h) Octavo escenario: en este escenario se hace la prueba de
liberación, para esta funcionalidad se revisa la lista de
direcciones de arrendamiento y elimina aquellas
direcciones que su tiempo ya haya caducado, cuando el
tiempo de arrendamiento se agota, el cliente envía de
nuevo un mensaje DHCP DISCOVER si este desea
renovar, si no, no se envía el mensaje.

Figura 13. Screenshot prueba 8

Figura 14. Fin de arrendamiento visto en el programa

V. CONCLUSIONES
Se pudo llegar a la conclusión a través de las distintas
pruebas y escenarios que la implementación del servidor
DHCP se realizó de manera correcta.
Tanto la implementación como el montaje del servidor
en físico fueron grandes pruebas a superar durante el
desarrollo, pruebas que afortunadamente se pudieron
superar de una forma óptima.

REFERENCIAS
[1] R. Droms. “RFC 2131 - Dynamic Host Configuration Protocol”,
Network Working Group, 1997.[Online]. Available:
https://www.ietf.org/rfc/rfc2131.txt.
[2] M. Andrés.. System Integrations with Free Software[Online]
Available: https://www.slideshare.net/amaneiro/dhcp-session
[3] S.Alexander. “RFC 2132 – DHCP Options and BOOTP Vendor
Extensions”, Network Working Group, 1997.[Online]. Available:
https://www.ietf.org/rfc/rfc2132.txt .