Compartir a través de

Diagnóstico de pérdida de paquetes

La pérdida de paquetes se produce siempre que un paquete de red no llega a su destino previsto. Algunas pérdidas de paquetes son normales y no siempre provocan problemas de red de nivel superior. En otros momentos, la pérdida de paquetes puede reducir el rendimiento y provocar un error en las interfaces de programación de aplicaciones (API) o las aplicaciones.

Captura y diagnóstico de pérdida de paquetes

El primer paso al realizar una investigación de pérdida de paquetes es capturar seguimientos del Monitor de paquetes (Pktmon), normalmente mediante el flujo de trabajo de la línea de comandos de pktmon. Pktmon puede capturar seguimientos de paquetes, atribuir la pérdida de paquetes local a razones específicas y ubicaciones de código, y recopilar estadísticas de pérdida de paquetes. Cuando se combina con el análisis de Wireshark del comportamiento de nivel de protocolo, los seguimientos de pktmon son suficientes para identificar las causas principales de muchos casos de pérdida de paquetes.

Si los diagnósticos de pktmon son inconclusos, se pueden capturar seguimientos de nivel de componente más exhaustivos mediante el netsh.exe trace start scenario=InternetClient comando o netsh.exe trace start scenario=InternetServer para escenarios de cliente y servidor, respectivamente. Una vez capturados los eventos, detenga el seguimiento mediante el netsh.exe trace stop comando . Estas trazas a nivel de componente son ruidosas y no están claras, pero a menudo contienen contexto adicional antes o después de eliminar un paquete local. En el caso de la pérdida remota, podrían indicar que el sistema local deduce la aparición de la pérdida de paquetes. Los rastros se pueden convertir en texto mediante netsh.exe trace convert nettrace.etl, abrirse en el Analizador de rendimiento de Windows o usarse con cualquier herramienta de seguimiento de eventos para Windows (ETW).

Si la tarjeta de interfaz de red (NIC) es sospechosa como causa de la pérdida de paquetes, puede supervisar sus contadores de descarte a través de cualquier interfaz de contadores de rendimiento o el cmdlet Get-NetAdapterStatistics .

Causas comunes de pérdida de paquetes locales

La pérdida de paquetes local es totalmente observable y puede deberse a diversos factores internos y externos.

  • Directiva local

    El software de inspección puede hacer que los paquetes de las máquinas remotas se quiten de forma predeterminada, por ejemplo, cuando el Firewall de Windows rechaza los intentos de conexión entrantes. La ciberseguridad o el software antimalware en el sistema también pueden causar estos problemas.

  • Recursos bajos

    Si el sistema o el socket se queda sin recursos para manejar el paquete, se descarta el paquete. Algunos ejemplos de límites de recursos son la memoria física en el sistema y los búferes de envío o recepción de sockets. Según el límite de recursos, estos eventos pueden durar solo microsegundos, por ejemplo, cuando la CPU del sistema no puede reaccionar lo suficientemente rápido como para un búfer de recepción completo.

  • Fallo de funcionamiento de ARP o ND

    Si el próximo salto de un paquete saliente no responde a las solicitudes de Protocolo de resolución de direcciones (ARP) o descubrimiento de vecinos (ND), los paquetes enviados a ese próximo salto se descartan en el sistema local. Los paquetes también pueden descartarse durante los procesos de ARP o ND si se supera el límite de la cola de paquetes ARP o ND. Normalmente, los paquetes ARP o ND no se descartan localmente y se consideran parte de la categoría de pérdida de paquetes remotos.

  • Sin ruta

    Si la capa de red no encuentra una ruta válida al destino, es posible que se quiten los paquetes.

  • Paquete no válido

    Si los encabezados de paquete no son válidos, es posible que se quite el paquete. Por ejemplo, los encabezados de paquete contienen una suma de comprobación o un valor de campo no válidos.

Causas comunes de pérdida de paquetes remotos

La pérdida remota de paquetes no es observable de manera directa en el equipo local cuando se descarta el paquete. Protocolo de Internet (IP) y la mayoría de las capas inferiores son de “mejor esfuerzo posible” y no confiables. El principio de un extremo a otro requiere que los puntos de conexión implementen la confiabilidad dentro de sus protocolos si se requiere resiliencia a la pérdida de paquetes. En algunos escenarios, el punto de conexión remoto o de red envía un mensaje de error específico del protocolo que indica el motivo de la pérdida. Sin embargo, en muchos casos, la única indicación de pérdida de paquetes es una falta de respuesta.

  • Congestión

    Los algoritmos de control de congestión basados en pérdida envían cada vez más rápido hasta que se pierde un paquete. Si el algoritmo deduce la pérdida se debe a la congestión, reduce temporalmente la velocidad de envío en respuesta. Estos algoritmos requieren una pequeña cantidad de pérdida para proporcionar una señal de retroalimentación.

  • Política de trabajo remoto

    La red o la máquina remota pueden quitar paquetes según su propia directiva.

  • Destino inaccesible

    Esto puede ocurrir si la máquina remota no tiene un socket enlazado al puerto remoto, la máquina remota está sin conexión o la red no puede encontrar una ruta de acceso a la máquina remota.

  • Pérdida de sesión

    Si la red (incluida la traducción de direcciones de red con estado, NAT, firewalls y equilibradores de carga) o la máquina remota se restablece o no ha recibido un paquete recientemente, su contexto de sesión puede expirar y se descartan los paquetes subsiguientes.

  • Pérdidas de la unidad máxima de transmisión (MTU)

    Si el tamaño del paquete supera el tamaño máximo de transmisión de un enlace de red a lo largo de la ruta hacia la máquina remota, una caída de MTU podría producir un error: se requiere fragmentación del Protocolo de mensajes de control de Internet (ICMP) o el paquete es demasiado grande.

Ejemplo de registros del Monitor de paquetes

Ejecute los comandos siguientes:

pktmon.exe start -c
pktmon.exe stop
pktmon.exe etl2txt PktMon.etl

El archivo PktMon.txt resultante contiene líneas similares a las siguientes:

[30]0000.0000::<DateTime> [Microsoft-Windows-PktMon] Drop: PktGroupId 8444249301423149, PktNumber 1, Appearance 0, Direction Rx , Type IP , Component 49, Filter 1, DropReason INET: transport endpoint was not found , DropLocation 0xE000460A, OriginalSize 402, LoggedSize 148
       Drop: ip: 192.168.5.88.50005 > 192.168.5.68.50005: UDP, length 374

Esta información indica que el paquete UDP entrante destinado al puerto 50005 se descarta ya que no hay un socket local ligado al puerto.

Ejemplo de trazas de Network Shell

Ejecute los comandos siguientes:

netsh.exe trace start scenario=InternetClient
netsh.exe trace stop
netsh.exe trace convert NetTrace.etl

El archivo NetTrace.txt resultante contiene líneas similares a las siguientes:

[30]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCPIP: Network layer (Protocol 1(ICMP), AddressFamily = 2(IPV4)) dropped 1 packet(s) on interface 13. SourceAddress = 192.168.5.68. DestAddress = 192.168.5.88. Reason = 9(Inspection drop). Direction = 0(Send). NBL = 0xFFFFE189BEAF3AC0.

Esta información indica que el paquete ICMP saliente ha sido descartado tras la inspección de la Plataforma de Filtrado de Windows (PFP). El siguiente paso para el PMA es seguir los pasos de solución de problemas de transmisiones en vivo del PMA.

En otro escenario, el punto de conexión remoto no reconoce un segmento TCP enviado previamente y, finalmente, se desencadena un temporizador de retransmisión local, lo que provoca que TCP vuelva a enviar algunos de los datos potencialmente perdidos:

[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: Connection 0xFFFFE189BD811AA0 0(RetransmitTimer) timer has expired.
[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: Tail Loss Probe Event Connection = 0xFFFFE189BD811AA0, Event = 2(TimerFired).
[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: Tail Loss Probe Send Connection = 0xFFFFE189BD811AA0 SndUna = 2526318360, SndMax = 2526321759, SendAvailable = 3399, TailProbeSeq = 2526320299, TailProbeLast = 2526321759, ControlsToSend = 0, ThFlags = 16.
[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: connection 0xFFFFE189BD811AA0 (local=192.168.5.68:55330 remote=6.6.0.27:443): TCP send event, SeqNo = 2526320299, BytesSent = 1460, CWnd = 18538, SndWnd = 197632, SRtt = 17631, RttVar = 4947, RTO = 300, RcvWnd = 65535, PacingRate = 0, State = 4(EstablishedState), CongestionState = 0, SndUna = 2526318360, SndMax = 2526321759, RecoveryMax = 0, RcvBufSet = 0(FALSE), MaxRcvBuf = 65535.
[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: connection = 0xFFFFE189BD811AA0 send tracker marked a transmit as rexmit. Start = 2526320299, End = 2526321759, Timestamp = 467744252, InFlightCount = 2, SackedBytes = 0, BytesInFlight = 4859.
[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: Connection 0xFFFFE189BD811AA0 0(RetransmitTimer) timer started. Scheduled to expire in 300 ms. Processor 31: LastInterruptTime 305324952689 100-ns ticks; LastMicrosecondCount 30532515324 msec

Información adicional