Una PC de la oficina tiene una IP 169.254.x.x y no navega. ¿Qué significa y cómo funciona el proceso DHCP que falló?

Una IP 169.254.0.0/16 es APIPA (link-local): el equipo se la autoasigna cuando no recibió respuesta de ningún servidor DHCP. Por eso no tiene gateway ni DNS y no sale de su segmento.

Cómo funciona DHCP (DORA):

• Discover: el cliente envía un broadcast UDP desde el puerto 68 hacia el 67 buscando servidores.
• Offer: el servidor ofrece una IP del pool con máscara, gateway, DNS y tiempo de lease.
• Request: el cliente pide formalmente esa oferta, también por broadcast, así los demás servidores saben cuál eligió.
• Ack: el servidor confirma y el cliente configura la interfaz. Si responde NAK, se reinicia el proceso.

Qué revisaría, de abajo hacia arriba:

• Capa física: cable, link en el switch, Wi-Fi asociado.
• Que el puerto esté en la VLAN correcta.
• Si el servidor está en otra red, que exista un relay configurado (por ejemplo ip helper-address en Cisco), porque el broadcast no atraviesa routers.
• Pool agotado en el servidor o servicio caído.
• Controles de seguridad: DHCP snooping con el puerto hacia el servidor no marcado como trusted, o port security bloqueando.

Comandos útiles:

# Windows
ipconfig /release
ipconfig /renew

# Linux: ver el intercambio en vivo
sudo dhclient -v eth0
sudo tcpdump -ni eth0 port 67 or port 68

Con tcpdump veo rápido si salen los Discover y si vuelve algún Offer: eso me dice si el problema está del lado del cliente o de la red y el servidor.

Decir que 169.254 es una IP 'del router' o de una red privada RFC1918. Saltar a reinstalar drivers sin revisar VLAN, relay o pool agotado, y no saber que el broadcast DHCP no cruza routers sin un relay.