DHCP parece la parte más resuelta de una red: "reparte direcciones y ya". Esa comodidad dura hasta que un teléfono IP aparece en la VLAN equivocada, hasta que necesitas arrancar cincuenta equipos por red sin tocarlos, o hasta que un colega te enseña una laptop con dirección 169.254.x.x y pregunta por qué no navega. En el viaje de un paquete vimos DHCP de pasada, como el que reparte la dirección al arrancar. Aquí bajamos al detalle, porque DHCP es menos un repartidor y más una capa de automatización de la red.
Repaso rápido: DORA
Todo empieza con el intercambio de cuatro pasos —Discover, Offer, Request, Acknowledge—: el equipo pregunta a la red, un servidor le ofrece una dirección, el equipo la pide y el servidor confirma. En ese ida y vuelta el equipo no solo recibe su IP, sino su máscara, su gateway y sus servidores DNS. Lo interesante es todo lo que ese "simple" intercambio esconde debajo.
DORA: los cuatro mensajes tras los cuales el equipo recibe dirección y configuración.
El lease no es para siempre (y por qué eso te salva)
La dirección es un préstamo con caducidad: un lease. Pero no expira de golpe. A la mitad de su vida (lo que se conoce como T1) el equipo intenta renovarlo, discretamente, con el mismo servidor. Si no obtiene respuesta, más adelante (T2, alrededor del 87% del tiempo) prueba con cualquier servidor DHCP disponible. Solo si nadie contesta hasta el final, suelta la dirección.
Ese diseño tiene una consecuencia práctica que tranquiliza: si tu servidor DHCP se cae un rato, nadie pierde su dirección de inmediato —los leases vigentes siguen valiendo hasta vencer—, lo que te da margen para levantarlo sin que la oficina entera se quede sin red. El costo del apagón aparece en otro lado: los equipos nuevos que arrancan en ese hueco no consiguen dirección. Y ahí es donde aparece la 169.254.
APIPA: el nombre de esa 169.254 que tanto asusta
Cuando un equipo lanza su Discover y nadie contesta, muchos sistemas no se quedan en blanco: se auto-asignan una dirección del rango 169.254.0.0/16 mediante APIPA (Automatic Private IP Addressing), estandarizado como direccionamiento link-local en el RFC 3927. Saber su nombre técnico importa porque reconocerla es medio diagnóstico hecho: si ves una 169.254, el equipo no encontró servidor DHCP. Punto.
¿Y por qué esa dirección no navega? Porque link-local significa, literalmente, "solo para hablar con vecinos de este mismo segmento": no es ruteable, no tiene gateway, no sale a ningún lado. No es el problema; es el síntoma. Cuando aparezca, la lista de sospechosos es corta: el DHCP está caído, se quedó sin direcciones libres, o —muy común— no hay relay en esa VLAN (llegamos a eso).
Reserva vs. IP fija a mano: casi siempre gana la reserva
Un servidor DHCP administra un ámbito (scope): el rango de direcciones que puede repartir en una subred, con sus exclusiones (más sobre esto en un momento). Dentro de eso, para un equipo que siempre debe tener la misma dirección —un servidor, una impresora, una cámara— tienes dos caminos, y suelen confundirse.
El primero es teclear la IP a mano en el equipo (estática manual). El segundo es una reserva: le dices al servidor DHCP "a esta dirección física (MAC), entrégale siempre esta misma IP". La reserva casi siempre gana, por tres razones: la gestión es central (si cambias el gateway o el DNS, lo actualizas una vez en el servidor y todos lo reciben, en vez de reconfigurar equipo por equipo); no hay conflictos, porque el servidor lleva la cuenta de qué entregó; y no dependes de una configuración manual que alguien olvidó documentar y que reaparece como un fantasma tres años después. La IP fija a mano se justifica en poca cosa: la infraestructura base de la que depende el propio DHCP —el gateway, a veces el DNS, el mismo servidor DHCP—.
Las exclusiones: dónde el servidor tiene prohibido repartir
Que una dirección esté dentro del ámbito no significa que el servidor deba entregarla. Casi siempre hay direcciones dentro de ese rango que ya están ocupadas por equipos configurados de forma estática —el gateway en la .1, un switch administrable, un servidor con IP fija, esa impresora que alguien clavó a mano—. Una exclusión es, literalmente, decirle al servidor: "estas direcciones caen en tu ámbito, pero no las prestes a nadie". Puedes lograrlo definiendo el pool para que no las incluya, o marcando un rango de exclusión explícito dentro de un ámbito más amplio; lo segundo es cómodo cuando quieres que el ámbito cubra toda la subred pero abriendo "huecos" para lo estático.
¿Por qué importa tanto? Por el error más silencioso y exasperante de DHCP: olvidar excluir. El servidor, sin saberlo, entrega la .10 a una laptop mientras una impresora lleva la .10 cableada a mano. Resultado: un conflicto de IP, ese "a veces imprime, a veces no" que se persigue durante horas sin entender que dos equipos se pelean la misma dirección. La regla de oficio que lo previene es simple: reserva un bloque bajo del rango —por ejemplo .1 a .20— como exclusión para toda la infraestructura estática, y deja que DHCP reparta de la .21 en adelante. Predecible y documentado.
Cuidado con no confundir dos ideas que sirven a propósitos opuestos: la exclusión dice "mantente lejos de esta dirección, la administra alguien más"; la reserva dice "esta dirección entrégala siempre a este equipo concreto". Una aparta; la otra fija. Entender cuándo usar cada una es la diferencia entre una red que se documenta sola y una plagada de conflictos que nadie sabe de dónde salen.
DHCP Options: la configuración que viaja con la dirección
La dirección es apenas el principio. DHCP entrega, junto con ella, un conjunto de parámetros numerados llamados opciones. Las de siempre pasan desapercibidas: gateway (opción 3), servidores DNS (opción 6), nombre de dominio (15), duración del lease (51), servidor de hora NTP (42). Pero hay un segundo grupo, el de propósito específico, donde DHCP deja de repartir direcciones y se vuelve una herramienta de arquitectura:
- Arranque por red e imaging (PXE): las opciones 66 y 67 le dicen a un equipo sin sistema operativo desde qué servidor y con qué archivo arrancar. Es la magia detrás de montar cincuenta equipos sin tocarlos uno por uno.
- Descubrimiento automático: las opciones 43 y 60 permiten que un punto de acceso encuentre solo a su controladora WiFi, o que un teléfono IP reciba su configuración y caiga en la VLAN de voz correcta sin que nadie lo toque.
- Rutas sin visitar cada equipo: la opción 121 empuja rutas estáticas a todos los clientes de una vez.
La idea de fondo: bien usadas, las opciones automatizan decisiones de red que, hechas a mano, serían cientos de configuraciones idénticas —y cientos de oportunidades de equivocarse—.
El punto que ata todo con las VLANs: el relay
Aquí está el detalle que más tickets de soporte genera, y que conecta directo con las redes segmentadas. El Discover es un broadcast, y un broadcast no cruza el router ni sale de su VLAN —recordemos que una VLAN es, precisamente, un dominio de broadcast independiente—. Entonces surge la pregunta: si el broadcast se queda encerrado en su subred, ¿cómo puede un solo servidor DHCP dar servicio a diez VLANs distintas?
La respuesta es el relay —el "ip helper-address" que se configura en el router o el switch de capa 3—. El relay escucha el Discover local, lo reenvía como unicast al servidor DHCP que vive en otra subred, y devuelve la respuesta al equipo. Por eso, cuando "la VLAN nueva no reparte direcciones" pero el cableado y el switch están bien, el sospechoso número uno es un relay que nadie configuró. El síntoma, otra vez, será una sala entera de equipos con dirección 169.254.
El relay (ip helper-address) es lo que permite que un solo servidor DHCP dé servicio a muchas VLANs.
El contrapeso honesto: un DHCP también es superficie de ataque
Sería deshonesto pintar DHCP solo como una comodidad. También es un punto débil. Un servidor DHCP pirata (rogue) —una laptop mal configurada, un router casero que alguien enchufó "para tener WiFi en su escritorio"— puede empezar a repartir direcciones y, peor, a anunciarse como gateway falso para colarse en medio del tráfico. La defensa se llama DHCP snooping: el switch aprende qué puertos tienen permitido responder peticiones DHCP (el del servidor, el del relay) y descarta las respuestas de todos los demás. No se activa a ciegas —hay que marcar bien los puertos "de confianza"—, pero conocerlo es parte de tratar la red como algo que se protege, no solo que se configura.
La idea que se queda
DHCP no es "el que reparte IPs". Es una capa de automatización: reparte, renueva, reserva, configura y —con el relay— cruza fronteras de red. Cuando entiendes el lease, el APIPA, las reservas, las opciones y el relay, dejas de pelearte con síntomas sueltos (una 169.254, una VLAN muda, un teléfono en la red equivocada) y empiezas a diseñar la red a propósito. Es un zoom a una de las paradas del recorrido completo de una red —y de las que más rinde entender bien—.