2026-06-02

Análisis PCAP de conflictos de direcciones IP duplicadas de ARP: búsqueda de cambios gratuitos en ARP, MAC y confusión en la puerta de enlace

Cómo diagnosticar conflictos de direcciones IP duplicadas, tormentas de ARP, ARP gratuito, asignaciones de MAC incorrectas, confusión de puertas de enlace y fallas intermitentes de LAN en capturas de paquetes.

Los conflictos de IP duplicados crean fallas intermitentes que parecen aleatorias. Un dispositivo funciona y luego se cae. La MAC de la puerta de enlace cambia. Se puede acceder a un servicio desde un host pero no desde otro. Los usuarios buscan "pcap de IP duplicada de ARP", "conflicto de ARP gratuito", "dos direcciones MAC de la misma IP", "MAC incorrecta de caché de ARP" y "captura intermitente de paquetes de LAN" porque los registros de aplicaciones normales rara vez exponen problemas de identidad de capa 2.

ARP asigna direcciones IPv4 a direcciones MAC en una red local. Si dos dispositivos reclaman la misma IP, el tráfico puede rebotar entre ellos o ir a la máquina equivocada.

La cirugía PCAP es útil porque la evidencia de ARP suele ser pequeña pero está oculta en una captura más grande. Necesita solicitudes ARP, respuestas, ARP gratuito, direcciones MAC, marcas de tiempo y fallas circundantes.

Cómo se ve una IP duplicada

Un signo clásico es la misma IP asociada a diferentes direcciones MAC:

10.0.0.25 is-at aa:aa:aa:aa:aa:aa
10.0.0.25 is-at bb:bb:bb:bb:bb:bb

If both appear close together, there may be an IP conflict, failover event, virtual IP movement, spoofing, or misconfigured device.

Gratuitous ARP

Gratuitous ARP announces or defends an IP address without being directly asked. It is normal in failover systems, DHCP address checks, and device startup. It is suspicious when multiple devices repeatedly announce the same IP.

Look for:

Repeated gratuitous ARP for one IP.
Different MAC addresses claiming the same IP.
ARP announcements after device reboot.
Gateway IP claimed by unexpected MAC.
Failover pair behavior vs accidental conflict.

Gateway confusion

If the default gateway IP maps to the wrong MAC, many connections fail. Hosts may send traffic to a device that is not the router. This can happen because of misconfiguration, stale ARP, malicious spoofing, or a failover system behaving incorrectly.

Preserve ARP packets around the time when TCP connections begin failing.

Checklist

Use this workflow:

Filter ARP traffic.
Identify the IP with changing MAC mappings.
Record every MAC claiming that IP.
Check whether one is the expected gateway/server/device.
Look for gratuitous ARP.
Correlate MAC changes with TCP resets, retransmissions, or outages.
Check DHCP logs for duplicate leases.
Inspect switch MAC address table if available.
Separate intentional HA failover from accidental conflict.
Preserve timestamps and MAC addresses when sharing evidence.

Final diagnosis

ARP duplicate IP conflicts are local-network identity failures. The packet evidence is direct: which MAC claimed which IP, when it changed, and what failed afterward.

PCAP Surgery helps isolate that evidence so an intermittent LAN problem can be traced to ARP behavior instead of being misdiagnosed as DNS, TCP, or application instability.

Respuesta basada en paquetes para «Análisis PCAP de conflictos de direcciones IP duplicadas de ARP: búsqueda de cambios gratuitos en ARP, MAC y confusión en la puerta de enlace»

La respuesta directa es que una etiqueta del analizador o un mensaje de la aplicación no determina la causa. Empieza por punto de captura y dirección; demuestra la última frontera correcta y la primera fallida. En «Análisis PCAP de conflictos de direcciones IP duplicadas de ARP: búsqueda de cambios gratuitos en ARP, MAC y confusión en la puerta de enlace», otro revisor debe poder encontrar el packet, hueco o intervalo que sostiene cada frase y saber qué evidencia podría refutarla.

Situar la captura en el camino

Registra client, server y cualquier proxy, load balancer, NAT o firewall. Indica interface, lugar, reloj, sistema y direcciones visibles. Una captura junto al client demuestra lo que llegó allí, no que el server no enviara. Una junto al server demuestra salida en ese punto, no tránsito completo. Antes de comparar dos puntos corrige clock offset y alinea flow tuple, TCP sequence o transaction ID.

Comprueba calidad: snap length, dropped packets, offload, capture filter, ring buffer y hora inicial. Un checksum incorrecto en host puede ser offload artifact. Un segmento grande puede provenir de GRO/TSO y no existir así en el cable. Un packet ausente en un archivo limitado no es network loss hasta demostrar que el punto debía verlo.

Leer fronteras en orden

Frontera	Evidencia correcta	Evidencia de fallo
Link e IP	dirección, addresses y ruta coherentes	ARP/NDP ausente, ICMP, MTU, asimetría
TCP	SYN, SYN-ACK, ACK y sequence	retransmission, RST, zero window, timeout
TLS	ClientHello, ServerHello y progreso	alert o límite SNI/ALPN/certificate
Aplicación	request completo y response relacionado	status, gap o cierre temprano
Usuario	response time o failure window	stall ligado a una frontera

Detente en la primera frontera sin éxito. Si TCP no termina, no empieces por HTTP. Si request llega al proxy pero no al upstream, el límite está en proxy o su camino. Si llega al upstream sin response antes del timeout, usa ACK y progreso de bytes para separar application delay de network loss.

Separar observación e hipótesis

La observación se puede señalar: «Client envió hasta cierta sequence; sender repitió un segmento tres veces y no apareció ACK avanzado en este punto». La hipótesis es «el camino perdió el segmento». Otra captura o dropped records pueden refutarla. Para cada hipótesis escribe una prueba favorable y una contraria.

Retransmission o duplicate ACK no asigna culpable. Reordering, loss, capture artifact y receiver delay producen marcas similares. Relaciona dirección, sequence, ACK, SACK, RTT, window y tiempo de aplicación. En DNS o DHCP enlaza transaction ID, addresses e intentos; en HTTP, request y response; en TLS, dirección del handshake.

Preservar el original

Calcula checksum y conserva el original sin cambios. Filtra, recorta y redacta una working copy. Registra input, transformación, hora, packet count antes/después, checksum y motivo. Tras reescribir timestamps o eliminar packets, esa copia pierde capacidad para algunas conclusiones de tiempo o secuencia.

Sustituye addresses e identificadores de forma constante para seguir el mismo endpoint. No elimines ports, directions o lengths necesarios. Guarda aparte el mapa secreto. Revisa límites de captura y exportación y el flujo general de PCAP Surgery.

QA antes de publicar

¿Título y respuesta tratan el mismo flow? ¿Cada duración nombra reloj y puntos? ¿Está identificada la primera frontera fallida? ¿Existe explicación alternativa? ¿Se repite cambiando una variable? ¿Se conserva el original? Declara el límite: «Esta captura demuestra comportamiento junto al client durante este intervalo; no demuestra la ejecución interna del server».

Semrush no se distribuye por plantilla. El término validado PCAP analyzer pertenece solo a la página del producto; este artículo conserva su pregunta técnica y no inventa volumen ni KD.

Libro de flow y prueba de descarte

Para «Análisis PCAP de conflictos de direcciones IP duplicadas de ARP: búsqueda de cambios gratuitos en ARP, MAC y confusión en la puerta de enlace», crea una fila por dirección: endpoints con alias, primer/último packet, bytes enviados y reconocidos, resets, retransmissions, requests y responses. No mezcles conexiones por compartir hostname; source port, inicio e initial sequence separan sessions. Con NAT o proxy documenta la relación de flows sin esperar iguales sequence o ports.

Calcular TCP, no contar etiquetas

Sigue next expected sequence del receiver. El payload mueve sequence por su longitud; SYN y FIN consumen un número. Duplicate ACK estable tras segmentos superiores apoya loss o reordering. SACK blocks muestran ranges recibidos, no dónde se perdieron. Si retransmission aparece junto al sender y no junto al receiver, prueba el tramo; si falta el segmento original en sender capture, revisa capture loss u offload.

Separa fast retransmit tras duplicate ACKs de RTO tras silencio. Compara RTT previo, advertised window, zero-window probes, burst y tamaño. No cada label es pérdida independiente: overlap, spurious retransmission o captura iniciada a mitad cambian la clasificación.

Medir tiempo con fronteras

Usa request first byte, request complete, response first byte y response complete. TTFB no equivale a tiempo de server sin punto y transporte. Retransmission antes de response añade posible network delay; request reconocido y silencio largo apoya application wait. Indica valor, unidad, clock y punto.

Con dos puntos alinea un packet distintivo en ambas direcciones, estima offset y usa intervals internos. Si clock es incierto, da un range. Compara ventanas correctas y fallidas de duración y carga similares.

Preguntas por protocolo

DNS: ¿ID, nombre y tipo coinciden, y retry cambia resolver o source port? DHCP: ¿Discover, Offer, Request y ACK pertenecen al mismo client identifier? TLS: ¿último handshake message por dirección y alert visible o cifrado? HTTP: ¿quién genera 4xx/5xx y existe upstream flow? TCP close: ¿quién envía FIN/RST y qué bytes quedan sin ACK?

Prueba decisiva y entrega

Elige dos hipótesis y una prueba que las separe. Captura al otro extremo separa network loss de measurement loss; desactivar offload en test comprueba artifact; request idéntico por path fijo prueba intermittency; log upstream contra packet boundary prueba application delay. Escribe resultados esperados antes.

Acepta cuando otro reviewer repite el cálculo con metadata, encuentra la misma frontera y entiende límites. Entrega original/derived checksum, filter, packet ranges y pasos de trim/redaction. Termina con owner, acción y condición medible.

Revisión de reproducción

Abre una connection nueva y repite tres veces con iguales entradas y filtros. Ports e initial sequence pueden cambiar, pero frontera, dirección y patrón deben repetirse. Informa éxitos y fallos. Una corrección cambia una variable y debe producir el cambio de packets previsto, no solo ocultar el mensaje.

Abre la copia derivada en otro equipo. El reviewer encuentra alias, clock, capture point, último éxito, primer fallo y alternativa. Busca hostname, query, header o payload sensible tras redaction, conservando lengths y directions necesarios. Enumera lo no probado: otra dirección, IPv6, reconnect o carga.

Cierra como demostrado dentro del alcance, todavía reproducible o pendiente por una captura concreta. No escribas «red arreglada» tras probar un solo flow.