2026-06-02

Destino ICMP inalcanzable y análisis PCAP de paquetes demasiado grandes: lo que le dice la red

Cómo analizar el destino ICMP inalcanzable, el puerto inalcanzable, el host inalcanzable, la fragmentación necesaria, el paquete demasiado grande, el filtrado de políticas y la evidencia de MTU de ruta en archivos PCAP.

A menudo se ignora ICMP hasta que algo se estropea. Entonces se convierte en una de las fuentes más claras de evidencia de la red. Una captura de paquete puede mostrar "Destino inalcanzable", "Puerto inalcanzable", "Host inalcanzable", "Fragmentación necesaria", "Paquete demasiado grande" o "Tiempo excedido". Los usuarios buscan "pcap de destino ICMP inalcanzable", "significado de puerto ICMP inalcanzable", "MTU de ruta de paquete demasiado grande" y "fragmentación necesaria Wireshark" porque los mensajes ICMP explican fallas que las aplicaciones TCP o UDP informan vagamente.

La cirugía PCAP es útil porque los mensajes ICMP son pequeños pero importantes. Son fáciles de perder al recortar una captura. Si los elimina, puede eliminar la explicación de la red.

ICMP es informe de errores

ICMP no transporta datos de la aplicación. Informa las condiciones de la capa de red. Para solucionar problemas, ICMP puede revelar:

Host de destino inalcanzable.
Red de destino inalcanzable.
Puerto inalcanzable.
Comunicación prohibida administrativamente.
Se necesita fragmentación.
Paquete IPv6 demasiado grande.
Se superó el TTL.
Redirecciones o comportamiento de enrutamiento.

Cada mensaje debe interpretarse con el paquete original que lo activó.

Puerto inalcanzable

Para UDP, el puerto inalcanzable es común. Si un host recibe UDP para un puerto cerrado, puede responder:

ICMP Destination Unreachable: Port Unreachable

This can explain DNS, syslog, telemetry, QUIC, RTP, or custom UDP failures. The application might call it a timeout, but the network capture shows an explicit rejection.

If no ICMP response appears, the packet may have been dropped silently.

Host or network unreachable

Host/network unreachable messages suggest routing or reachability problems. They may come from an intermediate router, firewall, gateway, or local host.

Important questions:

Who sent the ICMP message?
Which original packet triggered it?
Does it affect all destinations or one subnet?
Does routing change during the capture?
Is a VPN or tunnel involved?

The source of the ICMP message often identifies the device that knows about the problem.

Fragmentation needed and Packet Too Big

For IPv4 with Don't Fragment set, routers may send "Fragmentation Needed" when a packet exceeds path MTU. For IPv6, "Packet Too Big" is essential for Path MTU Discovery.

If these messages are present and the sender adapts, PMTUD works. If they are absent or blocked, large packets may vanish and the connection may stall.

This evidence is critical for VPN, tunnel, cloud overlay, and large TLS handshake problems.

Administratively prohibited

Some ICMP unreachable messages indicate policy filtering. That is different from a host being down. A firewall or router may explicitly say communication is prohibited.

If you see policy-related ICMP, the right team is often firewall/network policy, not application development.

Checklist

Use this process:

Filter ICMP and ICMPv6.
Identify message type and code.
Identify who sent the ICMP message.
Inspect the embedded original packet.
Correlate ICMP timing with application failure.
Preserve ICMP when trimming the capture.
For Packet Too Big, inspect MTU value and whether sender adapts.
For Port Unreachable, identify UDP service and port.
For policy messages, identify firewall or gateway source.
Compare with routing/VPN topology.

Final diagnosis

ICMP messages are not noise. They are network-layer evidence. Destination Unreachable, Port Unreachable, Fragmentation Needed, Packet Too Big, and policy messages can explain failures that applications report only as timeout or reset.

PCAP Surgery helps preserve these small but decisive packets so the final trace still contains the network's own explanation.

Respuesta basada en paquetes para «Destino ICMP inalcanzable y análisis PCAP de paquetes demasiado grandes: lo que le dice la red»

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 «Destino ICMP inalcanzable y análisis PCAP de paquetes demasiado grandes: lo que le dice la red», 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.

Respuesta directa y límite de aceptación

La respuesta breve a «Destino ICMP inalcanzable y análisis PCAP de paquetes demasiado grandes: lo que le dice la red» es: Cómo analizar el destino ICMP inalcanzable, el puerto inalcanzable, el host inalcanzable, la fragmentación necesaria, el paquete demasiado grande, el filtrado de políticas y la evidencia de MTU de ruta en archivos PCAP. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en PCAP Surgery.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: Destino ICMP inalcanzable y análisis PCAP de paquetes demasiado grandes: lo que le dice la

Para «Destino ICMP inalcanzable y análisis PCAP de paquetes demasiado grandes: lo que le dice la red», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 2: Cómo analizar el destino ICMP inalcanzable, el puerto inalcanzable, el host inalcanzable,

Cierre «Cómo analizar el destino ICMP inalcanzable, el puerto inalcanzable, el host inalcanzable, la fragmentación necesaria, el paquete demasiado grande, el » solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 3: ICMP es informe de errores

Para «ICMP es informe de errores», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 4: Puerto inalcanzable

Cierre «Puerto inalcanzable» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 5: Host or network unreachable

Para «Host or network unreachable», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 6: Fragmentation needed and Packet Too Big

Cierre «Fragmentation needed and Packet Too Big» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 7: Administratively prohibited

Para «Administratively prohibited», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 8: Checklist

Cierre «Checklist» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 9: Final diagnosis

Para «Final diagnosis», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 10: Respuesta basada en paquetes para «Destino ICMP inalcanzable y análisis PCAP de paquetes d

Cierre «Respuesta basada en paquetes para «Destino ICMP inalcanzable y análisis PCAP de paquetes demasiado grandes: lo que le dice la red»» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Destino ICMP inalcanzable y análisis PCAP de paquetes demasiado grandes: lo que le dice la red	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo analizar el destino ICMP inalcanzable, el puerto inalcanzable, el host inalcanzable, la fragmentación necesaria, el	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
ICMP es informe de errores	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Puerto inalcanzable	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Host or network unreachable	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Fragmentation needed and Packet Too Big	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: