Conflicto de IP detectado: encuentra al culpable rápido

Qué es realmente un conflicto de IP (y por qué parece aleatorio)

Un conflicto de IP no es un “error de red”. Es un error de contabilización. Dos hosts creen poseer la misma dirección IP en el mismo dominio de broadcast L2 (o en dos dominios que están puenteados por accidente). La red entregará paquetes felizmente a quienquiera que “gane” en ese momento la asociación entre IP y dirección de enlace (MAC para IPv4/ARP, o dirección L2 para IPv6/NDP). Esa asociación cambia con el tiempo, por eso la falla parece intermitente y maliciosa.

Lo que realmente cambia es la entrada de la caché de vecinos en otros dispositivos:

• En IPv4, las cachés ARP mapean IPv4 → MAC. Un conflicto provoca agitación en la caché ARP. Verás logs como “duplicate address detected”, “ARP flux” o “kernel: arp: duplicate address”.
• En IPv6, NDP (Neighbor Discovery Protocol) mapea IPv6 → link-layer. Los conflictos en IPv6 son menos frecuentes pero pueden ser más enrevesados porque puedes tener múltiples direcciones IPv6 (SLAAC + DHCPv6 + estáticas) y direcciones de privacidad que complican la atribución.

Los conflictos suelen aparecer en algunos escenarios:

• IP estáticas dentro del rango DHCP. Alguien configura manualmente 192.168.1.50 en una impresora porque “es más fácil”, y luego DHCP la asigna.
• VMs o contenedores clonados con identidad de red preservada. Se clona una plantilla, se duplica una MAC, o un error en gestión de configuración forza la misma IP en varios nodos.
• Servidor DHCP no autorizado. Un router doméstico conectado a un puerto de oficina empieza a ofrecer leases y gateways equivocados.
• Extensión de capa 2 no intencionada. Un puente, un parche VLAN mal hecho o una red estirada hace que dos ubicaciones compartan la misma subred por sorpresa.
• Tormentas de ARP gratuitas. Algunos dispositivos envían “yo tengo esta IP” en exceso durante failover o reinicio, y otros sistemas se lo creen.

Una cita que sobrevive a todo postmortem es una verdad sobre la fiabilidad atribuida a Richard Cook, a menudo parafraseada en círculos de operaciones: idea parafraseada: “Los sistemas tienen éxito porque la gente se adapta constantemente; fallan cuando esa adaptación no puede seguir el ritmo”. En conflictos de IP, la “adaptación” es la red que está constantemente reaprendiendo ARP/NDP—hasta que no puede más.

Broma #1: Un conflicto de IP es la única vez que dos máquinas están de acuerdo en algo y todos los demás sufren.

Guía rápida de diagnóstico

Esta es la parte que imprimes (o al menos interiorizas). Cuando estás bajo presión, no empieces reiniciando dispositivos al azar. Los reinicios pueden “arreglar” temporalmente cambiando la MAC vista por último, lo que destruye evidencia.

Primero: confirma que es un conflicto real y delimítalo

1. Identifica la IP en disputa a partir de logs/alertas/informes de usuarios.
2. Encuentra al menos dos direcciones MAC diferentes que reclamen esa IP (evidencia ARP/NDP). Si solo tienes una MAC, puedes estar persiguiendo un problema de routing o firewall.
3. Determina el dominio de broadcast/VLAN donde vive el conflicto. “Misma IP” solo es problema si está en el mismo segmento L2, o en segmentos puenteados que se comportan como uno.

Segundo: localiza al agresor físicamente/lógicamente

1. Desde un host en la misma VLAN, consulta ARP para la IP y anota la MAC.
2. En el switch, busca esa MAC en la tabla de reenvío para obtener el puerto del switch (o el trunk/uplink).
3. Sigue la MAC salto a salto hasta llegar a un puerto de acceso. Si es inalámbrico, terminarás en la tabla de asociación del WLC/AP en su lugar.

Tercero: decide si es DHCP, estática o virtualización

1. Revisa logs/leases DHCP para esa IP: ¿fue asignada, a qué MAC, cuándo?
2. Busca un servidor DHCP rogue si los clientes tienen gateway/DNS incorrectos o leases de una fuente extraña.
3. Revisa plataformas de virtualización por MACs clonadas o configuraciones estáticas duplicadas (plantillas VM, cloud-init, netplan, systemd-networkd, CNI de Kubernetes).

Condiciones de parada (cuando tienes suficiente)

• Puedes nombrar las dos direcciones MAC y mapear cada una a un dispositivo/puerto.
• Sabes cuál es la “legítima” (inventario, reserva DHCP, asignación estática documentada).
• Entiendes el mecanismo: estática dentro de DHCP, DHCP rogue, clonación, VLAN mal configurada, comportamiento de failover.

Datos interesantes y contexto histórico

• ARP es más antiguo que la mayoría de las prácticas operativas “modernas”. ARP se estandarizó a principios de los años 80, cuando las redes eran más pequeñas y la “IP duplicada” era mayormente error humano.
• La ARP gratuita tiene dos vidas. Se usa tanto para anuncios útiles (failover, refresco de caché) como para abuso (spoofing/poisoning). Mismo mecanismo, distinta intención.
• Algunos sistemas operativos defienden activamente su IP. Muchas pilas envían sondas ARP antes de usar una dirección, y pueden registrar “address conflict” si reciben respuestas.
• La detección de conflictos en DHCP existe, pero no es mágica. Muchos servidores DHCP pueden hacer ping ARP a una dirección antes de cederla. Esto reduce conflictos pero no evita una mala configuración estática posterior.
• Las MAC duplicadas pueden hacerse pasar por conflictos de IP. Si dos NIC comparten una MAC (clones defectuosos, MAC manual mal configurada), el aprendizaje del switch se vuelve inestable, causando que el tráfico rebote entre puertos.
• IPv6 intentó hacer esto menos frecuente. Duplicate Address Detection (DAD) está integrado en la neighbor discovery de IPv6. Ayuda, pero también crea sus propios modos de falla cuando L2 es inestable.
• “ARP flux” es algo real, no un término místico. Linux puede responder ARP en “la interfaz equivocada” si está configurado de forma laxa; hosts multihomed pueden confundir a los pares.
• Alta disponibilidad usa los mismos trucos que los atacantes. VRRP, CARP y muchos sistemas de clustering dependen de mover rápidamente una IP y actualizar cachés de vecinos; cuando están mal configurados, parecen conflictos.

Tu kit de herramientas: ARP, NDP, DHCP, switches y capturas

Resolverás la mayoría de los conflictos de IP con cuatro herramientas: tablas de vecinos, logs DHCP, tablas MAC de switches y capturas de paquetes. El truco es secuenciarlas para que cada respuesta reduzca el espacio de búsqueda. Si saltas directamente a tcpdump sin saber qué buscas, pasarás una hora leyendo ruido.

IPv4: ARP es la sala del tribunal

Cuando dos dispositivos reclaman una dirección IPv4, la anuncian con respuestas ARP (a veces no solicitadas). Todos los demás actualizan su caché. Tu trabajo es capturar esos anuncios y asociarlos con MACs y puertos.

IPv6: NDP y DAD son el mismo drama con direcciones más largas

En IPv6, los conflictos suelen exponerse durante DAD: el host propone una dirección y escucha objeciones. La objeción es una Neighbor Advertisement NDP. Capturar ese intercambio es oro porque incluye la dirección de enlace del agresor.

DHCP: el rastro documental (cuando existe)

DHCP aporta estructura: leases, reservas, marcas temporales. También aporta caos cuando hay más de un servidor DHCP, o cuando alguien usa IPs estáticas dentro del pool. Los logs DHCP responden dos preguntas vitales: ¿esta IP fue arrendada? y a quién?

Switches y controladores inalámbricos: donde está el cuerpo

Una vez que tienes la MAC del agresor, tu infraestructura de switching suele decirte el puerto (o el dispositivo aguas arriba). Eso convierte un “fantasma invisible de la red” en un ticket concreto: “Puerto Gi1/0/17 tiene la MAC aa:bb:cc:dd:ee:ff, etiquetado ‘Sala de conferencias’”.

Captura de paquetes: el suero de la verdad

Cuando los logs mienten, los paquetes no. Una captura corta centrada en ARP/NDP mostrará quién está reclamando la dirección y con qué frecuencia. Esa frecuencia importa: los sistemas HA harán ráfagas y luego silencio; los dispositivos rotos enviarán spam para siempre; el malware será extrañamente periódico.

Broma #2: Las tablas ARP son como los planos de asientos de una oficina: desactualizadas, a veces incorrectas y aun así todos confían en ellas.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son tareas reales que puedes ejecutar durante un incidente. Cada una incluye: el comando, una salida de ejemplo, qué significa y la decisión que debes tomar a continuación. Ejecútalas desde un host en la VLAN afectada siempre que sea posible; ejecutarlas desde “otro sitio” te dará datos de vecinos obsoletos o irrelevantes.

Task 1: Confirmar que la IP responde y ver resolución MAC (IPv4)

cr0x@server:~$ ping -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 56(84) bytes of data.
64 bytes from 10.20.30.40: icmp_seq=1 ttl=64 time=0.412 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=64 time=0.398 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.398/0.405/0.412/0.007 ms

Significado: La IP está viva (al menos ahora). Eso no prueba conflicto, pero prepara la caché ARP.

Decisión: Comprueba inmediatamente la entrada de vecinos; no esperes a que caduque.

Task 2: Inspeccionar la entrada ARP/neighbor (IPv4)

cr0x@server:~$ ip neigh show 10.20.30.40
10.20.30.40 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE

Significado: Tu host cree actualmente que 10.20.30.40 mapea a la MAC 00:11:22:33:44:55.

Decisión: Registra la MAC. Luego observa si cambia; los cambios son la firma de un conflicto.

Task 3: Vigilar la agitación de la caché ARP en tiempo real

cr0x@server:~$ watch -n 1 "ip neigh show 10.20.30.40"
Every 1.0s: ip neigh show 10.20.30.40

10.20.30.40 dev eth0 lladdr 00:11:22:33:44:55 STALE
Every 1.0s: ip neigh show 10.20.30.40

10.20.30.40 dev eth0 lladdr aa:bb:cc:dd:ee:ff REACHABLE

Significado: La MAC cambió de 00:11:22:33:44:55 a aa:bb:cc:dd:ee:ff. Ese es tu indicio decisivo: dos dispositivos responden por la misma IP.

Decisión: Ahora rastrea ambas direcciones MAC a través de la red. No “arregles” todavía; identifica ambos endpoints primero.

Task 4: Capturar reclamaciones ARP (quién grita “esta IP es mía”)

cr0x@server:~$ sudo tcpdump -ni eth0 arp and host 10.20.30.40
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:10.102345 ARP, Reply 10.20.30.40 is-at 00:11:22:33:44:55, length 28
12:01:10.508901 ARP, Reply 10.20.30.40 is-at aa:bb:cc:dd:ee:ff, length 28

Significado: Dos MAC diferentes emiten respuestas ARP para la misma IP. Esto es definitivo.

Decisión: Pasa a la búsqueda en switch/WLC para cada MAC. Si no tienes acceso, entrega estas MACs a quien sí lo tenga.

Task 5: Comprobar si tu host Linux es el culpable (no te rías)

cr0x@server:~$ ip -4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.20.30.41/24 brd 10.20.30.255 scope global eth0
       valid_lft forever preferred_lft forever

Significado: Este host no está configurado con 10.20.30.40. Bien—aun así vale la pena comprobarlo porque los problemas autoinfligidos son comunes.

Decisión: Si estuviera configurado con la IP disputada, detente y corrígela antes de perseguir la red.

Task 6: Buscar mensajes de kernel sobre direcciones duplicadas (Linux)

cr0x@server:~$ sudo journalctl -k --since "1 hour ago" | egrep -i "duplicate|arp|conflict"
Feb 05 11:58:22 server kernel: arp: 10.20.30.40 is detected on eth0 with different hwaddr aa:bb:cc:dd:ee:ff

Significado: El kernel observó una discrepancia en el mapeo IP/MAC. Esto confirma el problema desde la perspectiva del SO.

Decisión: Usa la marca de tiempo para correlacionar con logs DHCP, flaps en la CAM del switch o el reinicio de un dispositivo.

Task 7: Identificar al propietario “legítimo” vía lease DHCP (ejemplo ISC dhcpd)

cr0x@server:~$ sudo grep -n "10.20.30.40" /var/lib/dhcp/dhcpd.leases | tail -n 12
1827:lease 10.20.30.40 {
1828:  starts 3 2026/02/05 11:30:01;
1829:  ends 3 2026/02/05 23:30:01;
1830:  cltt 3 2026/02/05 11:30:01;
1831:  binding state active;
1832:  hardware ethernet 00:11:22:33:44:55;
1833:  uid "\001\000\021\"3DU";
1834:  client-hostname "acct-laptop-17";
1835:}

Significado: DHCP cree que 10.20.30.40 pertenece a la MAC 00:11:22:33:44:55 (con hostname del cliente incluido).

Decisión: Trata 00:11:22:33:44:55 como el cliente probablemente legítimo si tu alcance DHCP es correcto y no está siendo envenenado. Ahora busca aa:bb:cc:dd:ee:ff como el intruso.

Task 8: Revisar logs del cliente DHCP systemd-networkd (para ver qué servidor respondió)

cr0x@server:~$ journalctl -u systemd-networkd --since "2 hours ago" | egrep -i "DHCPv4|lease|server"
Feb 05 11:31:04 server systemd-networkd[612]: eth0: DHCPv4 address 10.20.30.41/24 via 10.20.30.1
Feb 05 11:31:04 server systemd-networkd[612]: eth0: DHCPv4 server: 10.20.30.2

Significado: Tu host obtuvo su lease del servidor DHCP 10.20.30.2. Si los clientes reciben leases de servidores distintos, puede haber un DHCP rogue.

Decisión: Si la IP del “servidor” es inesperada, escala al equipo de red para localizar el rogue y habilitar DHCP snooping/port security.

Task 9: Encontrar el puerto del switch a partir de una MAC (enfoque genérico vía ARP + workflow amigable con SNMP)

cr0x@server:~$ arp -an | grep "10.20.30.40"
? (10.20.30.40) at aa:bb:cc:dd:ee:ff [ether] on eth0

Significado: Tienes la MAC para buscar en la tabla CAM del switch.

Decisión: En el switch de acceso, ejecuta una búsqueda de dirección MAC (comando específico del vendor). Si no puedes, envía la MAC a quien sí pueda.

Task 10: Detectar flapping de MAC en bridge Linux (a veces el “switch” es un host)

cr0x@server:~$ bridge fdb show br0 | head
00:11:22:33:44:55 dev vnet3 master br0
aa:bb:cc:dd:ee:ff dev vnet7 master br0

Significado: En un host de virtualización puedes ver qué vNICs corresponden a cada MAC. Esto suele ser el camino más rápido en entornos con muchas VMs.

Decisión: Mapea vnet3/vnet7 a nombres de VM (libvirt, qemu, etc.) y revisa sus configuraciones IP o cloud-init.

Task 11: Revisar duplicado de configuración IP en netplan (común en provisión basada en imágenes)

cr0x@server:~$ sudo cat /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    eth0:
      addresses: [10.20.30.40/24]
      gateway4: 10.20.30.1
      nameservers:
        addresses: [10.20.30.2,8.8.8.8]

Significado: Este host está configurado estáticamente con la IP disputada. Si ves esto en múltiples máquinas por una imagen base, encontraste tu fábrica de conflictos.

Decisión: Arregla la canalización de provisión: direccionamiento único vía DHCP o asignación estática con plantillas. Luego cambia la IP del host ofensivo y limpia las cachés.

Task 12: Vaciar caché de vecinos después de la corrección (estabilización del cliente)

cr0x@server:~$ sudo ip neigh flush 10.20.30.40

Significado: Eliminaste el mapeo obsoleto para que el host pueda reaprender la MAC correcta rápidamente.

Decisión: Haz esto en servidores impactados tras la remediación, especialmente si tenían la MAC “equivocada” fijada y aún fallan.

Task 13: Comprobación de conflicto IPv6: ver entrada de vecinos e indicios DAD

cr0x@server:~$ ip -6 neigh show dev eth0 | head
fe80::a00:27ff:fe12:3456 lladdr 08:00:27:12:34:56 router REACHABLE
2001:db8:20:30::40 lladdr 00:11:22:33:44:55 STALE

Significado: Tienes un mapeo de vecino IPv6. Si alterna entre dos lladdrs, tienes la versión IPv6 del problema.

Decisión: Captura NDP (siguiente tarea) y busca Neighbor Advertisements desde múltiples fuentes.

Task 14: Capturar NDP IPv6 para una dirección específica

cr0x@server:~$ sudo tcpdump -ni eth0 "icmp6 and (ip6[40] == 135 or ip6[40] == 136)"
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:07:11.001122 IP6 fe80::1 > ff02::1:ff00:40: ICMP6, neighbor solicitation, who has 2001:db8:20:30::40, length 32
12:07:11.003210 IP6 fe80::a00:27ff:fe12:3456 > fe80::1: ICMP6, neighbor advertisement, tgt is 2001:db8:20:30::40, length 32
12:07:11.004001 IP6 fe80::b00:dead:beef:1 > fe80::1: ICMP6, neighbor advertisement, tgt is 2001:db8:20:30::40, length 32

Significado: Dos orígenes link-local diferentes anuncian la propiedad de la misma dirección IPv6. Eso es un conflicto.

Decisión: Extrae las direcciones L2 (usa -e en tcpdump si hace falta) y trázalas por switching/wireless como harías para ARP.

Task 15: Detectar ofertas DHCP rogue en el cable (inspección DORA)

cr0x@server:~$ sudo tcpdump -ni eth0 -vvv "udp and (port 67 or port 68)" -c 20
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:01.100001 IP (tos 0x0, ttl 64, id 1001, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:11:22:33:44:55, length 300, xid 0x1a2b3c4d
12:10:01.101111 IP (tos 0x0, ttl 64, id 2001, offset 0, flags [none], proto UDP (17), length 342)
    10.20.30.2.67 > 10.20.30.41.68: BOOTP/DHCP, Reply, length 314, xid 0x1a2b3c4d, yiaddr 10.20.30.41
12:10:01.101999 IP (tos 0x0, ttl 255, id 3001, offset 0, flags [none], proto UDP (17), length 342)
    192.168.0.1.67 > 10.20.30.41.68: BOOTP/DHCP, Reply, length 314, xid 0x1a2b3c4d, yiaddr 10.20.30.99

Significado: Dos servidores DHCP respondieron: 10.20.30.2 (esperado) y 192.168.0.1 (muy sospechoso en esta subred). Eso es un servidor DHCP rogue, que puede causar indirectamente conflictos de IP y definitivamente provoca enrutamiento incorrecto.

Decisión: Involucra a red/seguridad: corta el puerto, habilita DHCP snooping, localiza el dispositivo rogue por MAC desde el paquete DHCP (-e) y busca el puerto en el switch.

Tres mini-historias corporativas desde el frente

Historia 1: El incidente causado por una suposición errónea

La empresa estaba en medio de una migración de una red de oficina heredada a un diseño segmentado nuevo. Un pequeño equipo levantó una subred “temporal” para un laboratorio: la misma gama RFC1918 que producción, porque “está aislada”. Estaban confiados porque el switch del laboratorio estaba en otro armario y el router del laboratorio tenía un uplink WAN distinto. Aislada, por vibras.

Dos meses después, un contratista necesitó acceso remoto al laboratorio. Alguien añadió un túnel VPN y puenteó la VLAN del laboratorio al core del campus “solo por una semana”. Nadie actualizó los diagramas de red. Nadie actualizó los registros de IPAM. El túnel se quedó.

Entonces llegó la diversión: endpoints de producción empezaron a perder acceso intermitentemente a un servicio de archivos. La IP del servicio era estable; la MAC no. Helpdesk culpó al equipo de almacenamiento. Al almacenamiento le echó la culpa el firewall. El equipo de firewall culpó a DNS porque eso hacen los equipos de firewall cuando están aburridos.

El avance fue dolorosamente simple: una captura ARP mostró dos MACs reclamando la IP del servicio. Una era el servidor real. La otra era una VM del laboratorio configurada con un archivo netplan copiado y pegado de una página wiki. El laboratorio “aislado” se había convertido en parte del dominio de broadcast de producción por un error de bridging.

La solución no fue heroica. Fue cuidadosa: eliminar el puente, auditar la superposición de espacios RFC1918 y aplicar una regla—no solapar espacios de direcciones entre entornos a menos que puedas verificar separación L2 y L3. La postmortem no concluyó “la gente la cagó”. Concluyó “asumimos aislamiento sin verificar el camino”.

Historia 2: La optimización que salió mal

Otra organización estaba orgullosa de su aprovisionamiento rápido. Tenían una imagen VM golden que arrancaba deprisa y se unía al parque con dependencias externas mínimas. Para reducir el tiempo de arranque, decidieron preconfigurar direccionamiento estático en la imagen para un tier de servicio especial: menos llamadas DHCP, preparación más rápida, menos piezas móviles. En papel, ordenado.

La imagen incluía /etc/netplan/01-netcfg.yaml con una IP estática. El plan era “la sobrescribiremos por host durante el aprovisionamiento”. Pero la sobrescritura dependía de un paso cloud-init que fallaba ocasionalmente cuando el servicio de metadata era lento. Esas máquinas arrancaban con la IP empaquetada de todos modos.

No explotó inmediatamente. Humeó. Solo cuando ocurrían eventos de escalado—como ventanas de parche o un pico de tráfico—varias instancias arrancaban simultáneamente y colisionaban en la misma IP. El gráfico de monitorización parecía un latido: arriba, abajo, arriba, abajo. El equipo lo llamó “el flapper”.

Intentaron amortiguarlo: tiempos de caché ARP más largos, keepalives, “quizá es el balanceador”. Todo eso fue manejo de síntomas. La optimización real—IP estática horneada en la imagen—fue la raíz del caos.

La solución fue dejar de ser listos: quitar la dirección estática de la imagen base, dejar que DHCP haga su trabajo y usar reservas donde se necesitara IP estable. El tiempo de arranque aumentó ligeramente. La cantidad de incidentes se desplomó. Es un trade-off que la mayoría de empresas puede aceptar.

Historia 3: La práctica aburrida pero correcta que salvó el día

En un entorno fuertemente regulado, el equipo de red mantenía un hábito poco glamuroso: cada VLAN tenía scopes DHCP documentados, exclusiones y rangos estáticos reservados. Además, aplicaban que las direcciones “estáticas” solo se asignaban fuera del pool DHCP, nunca dentro. Sin excepciones, no “solo para una impresora”, nada “temporal”.

Una mañana, una ola de alertas de conflicto de IP golpeó un segmento de aplicaciones clínicas. El triage comenzó: las capturas ARP mostraron dos MACs para la misma IP—una perteneciente a un modelo de cliente ligero conocido y la otra desconocida. El equipo revisó el lease DHCP y vio inmediatamente el propietario previsto. Eso acotó el culpable a “algo estático o rogue”, no a “DHCP comportándose aleatoriamente”.

Después, hicieron lo más aburrido imaginable: búsqueda de MAC en switches. La MAC desconocida aterrizó en un puerto de acceso en una sala de reuniones que no debía estar en esa VLAN. El puerto estaba parcheado a un switch no gestionado pequeño. Desde allí: un router Wi‑Fi de consumo que alguien trajo de casa. Estaba puenteando y ofreciendo DHCP, y además tenía una IP estática configurada de un entorno previo que colisionaba con una dirección arrendada.

La resolución tomó minutos: deshabilitar el puerto, retirar el dispositivo, vaciar cachés de vecinos en servidores clave, confirmar que no había otros servidores DHCP rogue. El informe post-incident fue satisfactoriamente aburrido: scopes documentados y trazado por switch funcionaron exactamente como se diseñó.

Lo aburrido gana. No es un eslogan; es una verdad operativa.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “Funciona para algunos usuarios pero no para otros”

Causa raíz: Las cachés ARP difieren entre clientes; algunos tienen la MAC A para la IP, otros la MAC B. El servicio parece aleatoriamente accesible.

Solución: Captura respuestas ARP para confirmar reclamantes dobles, luego traza las MACs vía tablas de switches. Tras la remediación, vacía cachés de vecinos en clientes/servidores críticos.

2) Síntoma: “El conflicto ocurre solo después de reinicios o failover”

Causa raíz: Misconfiguración en par HA (VRRP/CARP/keepalived) donde ambos nodos creen ser master, o el failover envía gratuitous ARP demasiado agresivo y confunde a dispositivos aguas arriba.

Solución: Valida la máquina de estados HA, ajustes de preemption y health checks. Asegura que solo un nodo mantenga el VIP. Captura ARP durante el evento para probar el comportamiento.

3) Síntoma: “Vemos alertas de IP duplicada, pero la IP no responde a ping”

Causa raíz: La dirección se reclama vía ARP pero el firewall del host bloquea ICMP; o estás observando ARP spoofing / escaneo de seguridad; o el conflicto existe en otra VLAN distinta de donde pruebas.

Solución: No uses ping como la verdad. Usa evidencia ARP/NDP y la localización por switchport. Verifica el contexto VLAN (etiquetado trunk, VLAN de acceso).

4) Síntoma: “Dispositivos nuevos siguen recibiendo gateway/DNS incorrectos”

Causa raíz: Servidor DHCP rogue, a menudo un router doméstico o una VM mal configurada ejecutando dnsmasq.

Solución: Identifica las fuentes de ofertas DHCP con tcpdump, luego aisla por MAC y puerto de switch. Implementa DHCP snooping y bloquea puertos de servidor DHCP en el borde.

5) Síntoma: “La misma MAC aparece en dos puertos de switch”

Causa raíz: Dirección MAC duplicada (VMs clonadas, MAC fijada manualmente, firmware de NIC con errores) o un bucle/switch no gestionado causando inestabilidad en la CAM.

Solución: Confirma en inventario de virtualización; aplica generación única de MAC. Revisa bucles L2; asegúrate de que STP esté habilitado; considera seguridad de puerto para limitar movimientos de MAC.

6) Síntoma: “Conflictos de IP solo en Wi‑Fi”

Causa raíz: Peculiaridades de aislamiento/roaming, múltiples SSID puenteados a la misma VLAN inesperadamente, o un controlador inalámbrico mal configurado que reenvía DHCP incorrectamente.

Solución: Correlaciona por la tabla de clientes del WLC usando la MAC, verifica mapeo SSID→VLAN y busca puntos de acceso rogue que puenteen redes.

7) Síntoma: “Lo arreglamos, pero volvió al día siguiente”

Causa raíz: Arreglaste el síntoma (cambiaste la IP de un host) pero no el mecanismo (plantilla, solapamiento DHCP, dispositivo no gestionado que vuelve).

Solución: Disciplina de causa raíz: encuentra el dispositivo fuente y la razón por la que tenía esa IP. Actualiza IPAM, aplica exclusiones y añade detección.

Listas de verificación / plan paso a paso

Checklist de incidente: 15 minutos para claridad

1. Apunta: IP en disputa, VLAN/subred afectada, hora de la primera observación, quién lo reportó.
2. Desde un host en la misma VLAN: ip neigh show <IP> y registra la MAC.
3. Ejecuta: tcpdump -ni <if> arp and host <IP> durante 30–60 segundos. Registra todas las MACs vistas.
4. Revisa leases/logs DHCP: ¿está la IP arrendada? ¿a qué MAC? ¿Alguna IP de servidor DHCP inusual?
5. Traza la(s) MAC(s) en el switch: encuentra puerto de acceso o enlace upstream. Repite salto a salto.
6. Identifica el dispositivo: inventario de activos, OUI del vendor, hostname DHCP, mapeo de virtualización, entrada del controlador wireless.
7. Detén la hemorragia: deshabilita el puerto ofensivo, elimina la configuración estática o corrige el estado HA. Evita “simplemente reiniciar”.
8. Estabiliza: vacía cachés de vecinos en servidores clave, reinicia servicios afectados si es necesario.
9. Prevén recurrencias: arregla solapamientos de scope DHCP, actualiza IPAM, añade guardrails (snooping, reservas, corrección de plantillas).

Checklist de prevención: haz que los conflictos vuelvan a ser aburridos

• Mantén un rango estático reservado por VLAN y mantenlo fuera de los pools DHCP.
• Habilita detección de conflictos en el servidor DHCP donde esté disponible (chequeo ARP antes de ofrecer).
• Activa DHCP snooping y Dynamic ARP Inspection (donde el hardware lo soporte) en switches de acceso.
• Haz cumplir direcciones MAC únicas en plantillas VM; nunca incluyas IPs estáticas en imágenes golden a menos que también asegures unicidad.
• Registra y alerta sobre flaps de MAC para la misma IP (en firewall, switches o sensores pasivos).
• Mantén un proceso mínimo de “whois para MACs”: búsqueda OUI + mapeo con inventario interno.
• Documenta el comportamiento de VIPs HA (VRRP/CARP/keepalived) y prueba escenarios de split-brain.

Checklist de verificación post-incidente

1. Confirma que ARP/NDP para la IP resuelve exactamente a una MAC durante una vigilancia de 5–10 minutos.
2. Confirma que DHCP no tiene lease activo para esa IP ligado a la MAC “errónea” (o elimínalo).
3. Confirma que la tabla CAM del switch muestra la MAC en el puerto esperado y que es estable.
4. Confirma que las aplicaciones afectadas están estables: sin resets de conexión, sin timeouts intermitentes.
5. Escribe la causa raíz en una frase que incluya el mecanismo (no solo el dispositivo culpable).

Preguntas frecuentes

1) ¿Cómo sé que es un conflicto de IP y no DNS?

Los problemas de DNS no cambian direcciones MAC. Si ip neigh (o capturas ARP) muestran múltiples MACs para la misma IP, es un conflicto. DNS también puede estar roto, pero tiene una firma de fallo diferente.

2) ¿Por qué el problema va y viene?

Porque las cachés ARP/NDP caducan y se refrescan. Quien anuncie la propiedad más recientemente “gana” hasta que algo provoque un refresco (tráfico, expiración de caché, gratuitous ARP, neighbor solicitation).

3) ¿Puedo simplemente limpiar la tabla ARP para arreglarlo?

Limpiar cachés de vecinos puede restaurar la conectividad brevemente, pero no elimina al segundo reclamante. Es un paso de estabilización después de arreglar la causa subyacente, no una cura.

4) ¿Y si ambos dispositivos son “legítimos”, como un par HA?

Entonces solo uno debería ser master del VIP en cada momento. Si ambos lo reclaman, tienes split brain o failover mal configurado. Captura ARP durante el evento y verifica las transiciones de estado HA.

5) ¿Cómo encuentro el dispositivo si solo tengo una IP y no acceso al switch?

Usa una captura ARP para obtener la MAC. Luego usa el inventario que tengas: hostname del lease DHCP, tablas bridge del host de virtualización, listas de clientes del controlador wireless o registros de gestión de endpoints que indexen por MAC.

6) ¿Las redes IPv6 tienen conflictos de IP?

Sí, pero a menudo se detectan antes gracias a Duplicate Address Detection. Aun así, segmentos mal puenteados, IPv6 estáticas o imágenes clonadas pueden crear duplicados. Usa capturas NDP y tablas de vecinos igual que con ARP.

7) ¿Cuál es la forma más rápida de probar que hay dos dispositivos?

tcpdump en ARP (o NDP para IPv6) y un bucle watch en ip neigh show. Si la MAC alterna, tienes una prueba difícil de rebatir.

8) ¿Por qué las impresoras y dispositivos IoT aparecen tanto en estos incidentes?

Se configuran estáticamente “temporalmente”, se mueven entre redes y rara vez se actualizan. Además suelen vivir bajo escritorios o en armarios, lo que los convierte en villanos perfectos.

9) ¿Deberíamos poner todo en DHCP para evitar conflictos?

Para la mayoría de endpoints y servidores generales, sí. Para infraestructura que necesita direcciones estables, usa reservas DHCP o un rango estático documentado fuera del pool. “Unas estáticas, unas DHCP, sin documentación” es la invitación a conflictos.

Conclusión: pasos siguientes para evitar repeticiones

Cuando golpea un conflicto de IP, la jugada ganadora es dejar de adivinar y empezar a recopilar dos identificadores: la IP en disputa y las direcciones MAC reclamantes. A partir de ahí, es pura mecánica: mapear MAC a puerto (o vNIC de VM, o asociación Wi‑Fi), validar la intención DHCP y eliminar al reclamante extra.

Tus próximos pasos prácticos:

1. Adopta la guía rápida y exige evidencia ARP/NDP antes de “arreglos”.
2. Limpia el direccionamiento: mantén IPs estáticas fuera de pools DHCP y documenta rangos reservados.
3. Endurece el borde: DHCP snooping, inspección ARP y políticas de puerto sensatas donde tu hardware lo soporte.
4. Corrige tus plantillas: nada de IPs estáticas horneadas, nada de MACs duplicadas y nada de configuraciones “temporales” que se vuelven permanentes.

Si haces esas cuatro cosas, “IP conflict detected” volverá a ser una curiosidad rara en lugar de un personaje recurrente en tu cola de incidentes.