Teoría DHCP: asignación automática de direcciones IP
Configurar manualmente la dirección IP, máscara, gateway y servidores DNS en diez computadoras es manejable. Hacerlo en trescientas se convierte en una tarea inviable. Para resolver esto existe el protocolo DHCP (Dynamic Host Configuration Protocol), el mecanismo que permite que un dispositivo reciba toda su configuración de red automáticamente al conectarse. En esta clase analizamos cómo funciona el intercambio entre cliente y servidor, y también analizaremos todos los campos en los headers de los mensajes intercambiados.
¿Qué lograrás con esta clase?
- Comprender qué tareas resuelve el protocolo DHCP en redes con muchos dispositivos.
- Identificar los componentes del modelo cliente/servidor en una implementación DHCP.
- Reconocer los cuatro mensajes del proceso DORA: Discover, Offer, Request y Ack.
- Diferenciar qué mensajes del proceso DHCP viajan en broadcast y cuáles en unicast.
- Interpretar los campos relevantes de cada mensaje DHCP de cara al examen CCNA.
- Distinguir qué tipo de dispositivos conviene configurar con DHCP y cuáles con direcciones estáticas.
Para qué sirve DHCP y características generales
El protocolo DHCP asigna de manera automática información de direccionamiento IPv4 (o IPv6) a los dispositivos de una red: dirección IP, máscara, gateway, servidores DNS, e incluso parámetros adicionales que son necesarios para otros dispositivos. Funciona sobre un modelo cliente/servidor donde el cliente solicita los datos y un servidor previamente configurado los entrega. En la clase desarrollaremos los equipos que se encargan de entregar direccionamiento, qué se configura del lado del servidor, y cómo es el flujo de mensajes desde la perspectiva del usuario que se conecta a una red por primera vez.
El proceso DORA: Discover, Offer, Request y Ack
El intercambio completo entre cliente y servidor DHCP se conoce como DORA, un acrónimo que recoge los cuatro mensajes que conforman el proceso: Discover, Offer, Request y Ack. Cada uno cumple una función concreta y se envía con un tipo de comunicación distinto: algunos en broadcast y otros en unicast. Mostraremos el flujo completo sobre una topología real para que vean cómo se mueve cada mensaje entre los dispositivos de la red.
Detalles operativos, casos especiales y buenas prácticas
Cada mensaje DHCP transporta varios campos, pero solo algunos son relevantes a nivel CCNA. Veremos los campos que el examen evalúa con frecuencia, qué información contienen en cada uno de los cuatro mensajes y cuáles cambian según la implementación del sistema operativo (porque DHCP, definido en el RFC 2131, deja margen para variaciones).
También hablaremos sobre procesos de renovación de préstamo, mecanismos de seguridad que basan su funcionamiento en este protocolo, y mucho más.
Si quieres dominar el funcionamiento del protocolo DHCP en redes empresariales, esta clase es para ti. ¡Suscríbete!.
❓ Preguntas Frecuentes
¿Qué es DHCP y para qué se utiliza?
DHCP (Dynamic Host Configuration Protocol) es el protocolo que asigna automáticamente direcciones IP, máscara, gateway y servidores DNS a los dispositivos de una red. Permite que un equipo se conecte y obtenga toda su configuración de red sin intervención manual. Cómo se configura el lado servidor y qué parámetros se pueden entregar lo desarrollamos durante la lección.
¿Qué puertos UDP utiliza DHCP?
DHCP utiliza dos puertos UDP: el 67 y el 68. La asignación depende de quién origina el mensaje, ya que cliente y servidor utilizan combinaciones específicas en cada caso.
📚 Recursos relacionados
🔗 Recursos complementarios
¡PARTICIPEMOS!
Si te quedaron dudas de la lección, escríbela a continuación y así todos podemos participar y ayudarte.
¿Quieres participar en los debates?… por favor
suscríbete
-
Hola Roberto!
Como tú lo mencionas siempre hay «excepciones» a las reglas, tal vez algún cliente tuyo no soporta DHCP, o tal vez algún cliente se encuentra en una red bastante aislada y la comunicación con el servidor DHCP se complica, en fin… hay casos en los cuales no podemos utilizar DHCP y por lo tanto deberíamos realizar las configuraciones de manera manual en todos los dispositivos finales. Sin embargo, en una red en condiciones normales, TODOS los parámetros de direccionamiento IP (IP, Mascara, Gateway y servidores DNS) deberían ser entregados a través de DHCP. Es una mala práctica realizar una configuración manual ya que a medida que tu red crece tu trabajo administrativo para realizar las configuraciones manuales también va creciendo. Todas estas configuraciones de IP deberían ser centralizadas en un servidor DHCP.
Por el otro lado, para el tema del examen considera que Si o Si deberías entregar todos estos parámetros a través de un servidor DHCP.
Atento a tus comentarios.
Saludos cordiales
En la pregunta. 6. ¿Qué número de puerto de destino encontraremos en el header del protocolo UDP en un mensaje DHCP Discover?
53
21
0x0806
67
68
marco la opción de puerto 68 y a la hora de revisar el cuestionario me enmarca como si marcara el puerto 67.
Hola Milquicidic!
Efectivamente el puerto de destino de un mensaje DHCP Discover es el puerto 67! =) … esto lo vemos en el minuto 10 de la clase. Si marcas 68 (respuesta errónea) el cuestionarlo te mostrara que deberías marcar la opción 67. Vemos en nuestros registros que en tus 5 intentos marcaste la opción 68 (respuesta errónea)
Intenta de nuevo y coméntanos.
Atento a tus comentarios y pruebas.
Saludos cordiales.
Hola Alvaro.
En la explicación del protocolo DHCP, comentas, que la respuesta SERVIDOR -> CLIENTE del mensaje DHCP ACK es enviada como IP destino a la IP del cliente. Pero, si hasta que el cliente no reciba el DHCP ACK del servidor no llega a tener IP válida en la red… ¿Como puede ser que le enviemos la trama como IP destino (el host que va a configurar)? Teoricamente esa IP aun no existe en la red por que el host no ha terminado de «levantar» con esa IP. ¿No sería más acertado que esa respuesta DHCP-ACK se enviase como IP destino: 255.255.255.255?
Un saludo.
Hola Jose!
Esto se explica en el RFC, te copio el texto completo respecto a este tema:
» Normally, DHCP servers and BOOTP relay agents attempt to deliver
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
unicast delivery. The IP destination address (in the IP header) is
set to the DHCP ‘yiaddr’ address and the link-layer destination
address is set to the DHCP ‘chaddr’ address. Unfortunately, some
client implementations are unable to receive such unicast IP
datagrams until the implementation has been configured with a valid
IP address (leading to a deadlock in which the client’s IP address
cannot be delivered until the client has been configured with an IP
address).
A client that cannot receive unicast IP datagrams until its protocol
software has been configured with an IP address SHOULD set the
BROADCAST bit in the ‘flags’ field to 1 in any DHCPDISCOVER or
DHCPREQUEST messages that client sends. The BROADCAST bit will
provide a hint to the DHCP server and BOOTP relay agent to broadcast
any messages to the client on the client’s subnet. A client that can
receive unicast IP datagrams before its protocol software has been
configured SHOULD clear the BROADCAST bit to 0. The BOOTP
clarifications document discusses the ramifications of the use of the
BROADCAST bit
»
Como puedes ver, se tienen mecanismos para ambas situaciones, hay dispositivos que aceptan que los mensajes sean enviados a la IP que se está negociando. En el caso que no tengas esos dispositivos, el mensaje debería enviarse como broadcast como tú lo sugieres.
Esto la verdad va depender mucho del sistema operativo donde se implementa el protocolo, si tu haces una captura en Wireshark en Windows 10, veras que el mensaje ACK es enviado a la IP que se ofrece al cliente. Una vez se recibe la confirmación a través del ACK, el cliente utiliza el protocolo ARP para determinar si otro dispositivo en la red está utilizando esa IP para descartarla.
Todo esto lo puedes ver acá: RFC: https://datatracker.ietf.org/doc/html/rfc2131#section-4.4
Espero que ahora quede claro.
Saludos! =)
- Debes estar registrado para responder a este debate.
.
