Hay una pregunta que se repite en cada red y que ni la GUI ni el DHCP contestan bien: "este equipo debería estar conectado, pero no lo alcanzo… ¿siquiera está en la red?". No tiene una IP por DHCP, o no sabes si la tomó, o le pusieron una fija y nadie anotó cuál. ¿Está vivo en el cable o ni siquiera enchufado?
El comando que me saca de este apuro casi cada semana es de los más infravalorados del CLI: get system arp. Es tan simple que se ignora, y responde la pregunta a nivel de enlace —donde vive la verdad—, completamente al margen del DHCP.
Por qué ARP no miente
La tabla ARP es el mapa de quién está hablando de verdad en cada interfaz: qué dirección MAC corresponde a qué IP, en qué puerto y hace cuánto se le oyó. Y aquí está lo clave: un equipo aparece en la tabla ARP si está transmitiendo, tenga o no una concesión de DHCP. DHCP es opcional; ARP es inevitable —cualquier dispositivo que quiera hablar IP en la red tiene que resolver direcciones por ARP. Por eso ARP es la prueba de vida de nivel 2: si el equipo está ahí y transmite, está en la tabla, aunque nadie le haya dado una IP.
get system arpAddress Age(min) Hardware Addr Interface
192.168.10.1 0 00:09:0f:aa:bb:cc port2
192.168.10.20 2 00:0c:29:1a:2b:3c port2
192.168.10.87 0 b8:27:eb:4d:5e:6f port2
10.0.0.1 5 00:09:0f:11:22:33 port1Tres columnas hacen el trabajo:
- Address / Hardware Addr: la IP y su MAC. Si el equipo "perdido" aparece aquí, está vivo y en la red —punto. El problema es otro (ruteo, política, la IP que asumiste mal), no conectividad física.
- Age: hace cuántos minutos se le oyó. Un
Agebajo significa "acaba de hablar"; uno que sube y sube y luego desaparece, un equipo que se fue. - La MAC como identidad: los primeros tres octetos (el OUI) identifican al fabricante. ¿Un MAC misterioso que empieza en
b8:27:eb? Es una Raspberry Pi. La MAC te dice qué es el equipo desconocido antes de ir a buscarlo físicamente.
Para más detalle está diagnose ip arp list, y si sospechas entradas viejas envenenando tu diagnóstico, execute clear system arp table la vacía y deja que se repueble con lo que de verdad está hablando ahora.
El caso real: el pool DHCP que se llenó de fantasmas
Hace poco nos tocó exactamente este escenario. Dispositivos nuevos no lograban conectarse a la red —simplemente no obtenían dirección—, mientras que los de siempre funcionaban. El síntoma apuntaba a DHCP, y en efecto: el pool estaba lleno. Cero direcciones disponibles para repartir.
Pero la red no tenía tantos equipos como para agotar el pool. ¿Entonces qué lo estaba consumiendo? La lista de concesiones lo reveló:
execute dhcp lease-list
IP MAC Hostname Type Expires
192.168.10.20 00:0c:29:1a:2b:3c PC-VENTAS-03 dynamic 23h
192.168.10.40 00:1b:44:11:3a:b7 (baja-2024) reserved never
192.168.10.41 00:1b:44:11:3a:c2 (baja-2024) reserved never
192.168.10.42 00:1b:44:11:3a:d9 (baja-2024) reserved never
...Ahí estaba el fantasma: un montón de reservas —direcciones apartadas para MACs específicas— de equipos que se habían dado de baja hacía tiempo. Nadie limpió esas reservas al decomisionar el hardware, así que seguían ocupando lugar en el pool aunque los equipos ya no existieran. El cruce fue directo: esas MACs reservadas no aparecían en la tabla ARP —o sea, no había nadie de ese lado del cable— pero seguían apartando su IP. Direcciones ocupadas por equipos muertos, mientras los vivos se quedaban sin.
La lección operativa es incómoda de tan obvia: decomisionar un equipo incluye liberar su reserva de DHCP. Casi nadie lo hace, y las reservas fantasma se acumulan en silencio durante años hasta el día que el pool se llena y una compra nueva "no conecta a la red" sin razón aparente. Cruzar execute dhcp lease-list contra get system arp —lo reservado contra lo que de verdad está vivo— es cómo cazas ese problema en minutos.
Dónde encaja en tu caja de herramientas
ARP es la capa de enlace; complementa lo que ya viste en el resto de la serie. Cuando el debug flow no explica el problema y el triage de rendimiento sale limpio, muchas veces la respuesta está más abajo: el equipo ni siquiera estaba donde creías, o su IP no era la que asumiste. Empezar por "¿está en la tabla ARP?" te ahorra media hora de perseguir un problema de capa 3 que en realidad era de capa 2.
Preguntas frecuentes
help ¿Cómo sé si un equipo está en la red si no tiene IP por DHCP?
Con get system arp en el FortiGate. La tabla ARP mapea las direcciones MAC a las IP que están hablando en cada interfaz, independientemente del DHCP: si el equipo está conectado y transmitiendo, aparece en la tabla aunque no haya tomado una concesión de DHCP. Es la prueba de vida a nivel de enlace.
help ¿Por qué se llena un pool de DHCP si no hay tantos equipos?
Una causa frecuente y silenciosa son las reservas fantasma: direcciones apartadas para MACs de equipos que ya se dieron de baja pero cuya reserva nunca se eliminó. Siguen ocupando lugar en el pool indefinidamente. Cruzar execute dhcp lease-list contra la tabla ARP revela cuáles reservas corresponden a equipos que ya no existen.
help ¿Qué me dice la dirección MAC de un equipo desconocido?
Sus primeros tres octetos (el OUI) identifican al fabricante del adaptador de red. Eso te da una pista inmediata de qué es el equipo misterioso (una Raspberry Pi, una cámara, una impresora) antes de tener que rastrearlo físicamente en la red.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →