Este documento describe los fundamentos de TCP, el análisis detallado de paquetes de Wireshark y la resolución de problemas práctica para optimizar el rendimiento de extremo a extremo.
Cisco recomienda que tenga conocimiento sobre estos temas:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
Nota: Cualquier pregunta sobre la configuración y la interoperabilidad del software o hardware de terceros queda fuera del soporte de Cisco. El uso de herramientas de terceros es un esfuerzo para demostrar su configuración y funcionamiento con los equipos de Cisco.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
El protocolo de control de transmisión (TCP) es un protocolo de capa de transporte fundamental que funciona en la capa 4 del modelo OSI y proporciona una entrega fiable, ordenada y verificada por error de un flujo de bytes entre aplicaciones que se comunican a través de una red IP.
El diagrama representa la pila TCP/IP en la que un segmento TCP (capa 4) se encapsula dentro de un paquete IP (capa 3) y, a continuación, dentro de una trama Ethernet (capa 2) definida por IEEE 802.3. Este enfoque por capas garantiza la comunicación modular, en la que cada capa agrega su propia información de control (encabezados) para garantizar la entrega, el enrutamiento y la integridad de los datos.

El encabezado Ethernet es generalmente de 14 bytes, compuesto por:
Además, las tramas Ethernet incluyen una cola de secuencia de comprobación de tramas (FCS) de 4 bytes para la detección de errores en la capa 2. IEEE 802.3 define la trama, los tamaños de trama mínimos y máximos y las restricciones de entrega física que afectan directamente a los protocolos de capa superior como TCP.
El encabezado IPv4 tiene un tamaño mínimo de 20 bytes, ampliable hasta 60 bytes con opciones. Los campos clave incluyen:
La capa IP es responsable del direccionamiento lógico y el routing a través de las redes, pero no garantiza la fiabilidad.
El encabezado TCP varía de 20 a 60 bytes según las opciones. Los campos clave incluyen:
TCP añade entrega fiable, secuenciación adecuada y control de flujo a la comunicación IP.
Las opciones TCP amplían el protocolo base. Los más comunes incluyen:
Tanto los indicadores SYN como FIN consumen cada uno un número de secuencia, incluso cuando no hay carga útil. TCP funciona mediante un modelo de secuenciación orientado a bytes, donde cada byte transmitido (y los indicadores de control específicos) avanzan en el espacio de la secuencia. Este comportamiento es esencial para un análisis preciso de TCP en capturas de paquetes y para diagnosticar inconsistencias de secuenciación o reconocimiento.
ACK = SEQ + Payload Length + (SYN ? 1: 0) + (FIN ? 1: 0)
Where:
Cálculo ACK:
Esto refleja un escenario donde los datos se envían durante el intercambio de señales TCP. Tanto la carga útil como el indicador SYN consumen espacio de secuencia.
Cálculo ACK:
Esto muestra que TCP puede incluir datos durante el desmontaje de la conexión, y tanto la carga útil como el indicador FIN incrementan el número de secuencia.
El tamaño máximo de segmento (MSS) define la carga útil máxima que TCP puede enviar en un segmento.
Si hay opciones TCP, MSS se reduce en consecuencia. MSS se negocia durante el protocolo de enlace de tres vías TCP y evita la fragmentación en la capa IP.
El tamaño máximo de segmento (MSS) se intercambia durante el protocolo de enlace de tres vías TCP mediante la opción MSS en paquetes SYN:
Cada lado está diciendo efectivamente:
Esta es la carga útil TCP más grande aceptada.
MSS no se negocia como un único valor acordado.
En su lugar:
Por lo tanto:
En una pila TCP que funcione correctamente: No.
El Tamaño de la ventana define la cantidad de datos que el receptor puede aceptar sin reconocimiento.
Qué es:
Propósito:
Dónde obtenerlo:
Variabilidad de proveedor/sistema operativo:
Condición de ventana cero:
Mecanismos variables de Windows
Uso de Troubleshooting:
En esta sección se describe una metodología práctica para diagnosticar si un switch Cisco Nexus con NX-OS está afectando al reenvío de tráfico TCP o si presenta problemas de rendimiento. El enfoque se presenta a través de un escenario hipotético.
Cuando se observa latencia de TCP o degradación del rendimiento, es común sospechar inicialmente que la red lo está causando. Sin embargo, esta suposición debe validarse a través de un análisis controlado por datos. El método autorizado para la resolución de problemas de TCP es la captura de paquetes, que se realiza idealmente:
Esto garantiza la visibilidad del protocolo de enlace de tres vías TCP, donde se negocian parámetros críticos como MSS, Window Scale y SACK y no se repiten más adelante en la sesión. Si no es posible realizar capturas simultáneas, el análisis puede continuar con una sola captura, pero las conclusiones son limitadas.
Definición de escenario
Un usuario ha identificado que el proceso de copia de seguridad de un conjunto de datos de aplicación de aproximadamente 7,5 TB, que anteriormente se completaba en unas 9 horas, ahora está tardando casi 21 horas. Aunque las sesiones TCP entre el cliente y el servidor se siguen estableciendo correctamente, el aumento significativo en la duración de la copia de seguridad sugiere una degradación potencial en el rendimiento o en el rendimiento general de TCP. Dado que el switch Nexus es el único dispositivo de red en la ruta y también proporciona funcionalidad de gateway de capa 3, el administrador de la red sospecha que el switch Nexus es la causa del problema.

Linux: ping -c 10 -I 10.93.19.8 -s 1472 -M do 10.91.2.35
Windows: ping -n 10 -l 1472 -f 10.91.2.35
¿Por qué 1472 bytes?
Qué se puede concluir
Cómo utilizar esto para solucionar problemas
Relevancia práctica para TCP
Para solucionar de forma eficaz los problemas de rendimiento de TCP en un switch Cisco Nexus 9000, es esencial determinar qué interfaces reciben y reenvían el tráfico entre el origen y el destino.
En las topologías simples, esto se puede inferir directamente de las conexiones físicas. Por ejemplo, si el cliente está conectado a Ethernet1/1 y el servidor a Ethernet1/2, la trayectoria del tráfico es directa. Sin embargo, en entornos reales con varias interfaces activas, canales de puerto o configuraciones vPC, esta identificación no siempre es trivial.
En estos casos, el enfoque recomendado es utilizar el módulo analizador de lógica incorporada (ELAM), que proporciona visibilidad en el nivel ASIC (hardware de plano de datos).
ELAM le permite capturar un paquete mientras es procesado por la canalización de reenvío y revela información crítica como:
Este método es significativamente más preciso que confiar en las herramientas del plano de control, ya que refleja la ruta de reenvío de hardware real.
Es importante tener en cuenta que ELAM captura sólo un paquete a la vez, por lo que los criterios de filtrado deben definirse con precisión para que coincidan con el tráfico deseado (por ejemplo, IP de origen, IP de destino, puerto TCP). Si los filtros son demasiado amplios, existe el riesgo de capturar tráfico no relacionado como ICMP o UDP en lugar del flujo TCP deseado.
Además, este proceso debe repetirse para ambas direcciones de tráfico:
En entornos que utilizan vPC o ECMP, el tráfico se puede equilibrar en función de la carga a través de varias rutas. Como resultado, el tráfico de reenvío y retorno puede atravesar diferentes switches o interfaces. En estos casos, la ELAM debe ejecutarse en cada switch Nexus relevante para garantizar una visibilidad completa.
Al identificar con precisión las interfaces de entrada y salida, el alcance de la resolución de problemas se reduce significativamente, lo que permite una validación centrada de los contadores de interfaz, las políticas de QoS, la configuración de MTU y los puntos de congestión potenciales a lo largo de la ruta de reenvío exacta.
Este ejemplo filtra el tráfico con la IP de origen 10.93.19.8, la IP de destino 10.91.2.35 y el puerto de destino TCP 445.
Configuración de ELAM
switch# debug platform internal tah elam
switch(TAH-elam)# trigger init
Slot 1: param values: start asic 0, start slice 0, lu-a2d 1, in-select 6, out-select 0
switch(TAH-elam-insel6)# set outer ipv4 src_ip 10.93.19.8
switch(TAH-elam-insel6)# set outer ipv4 dst_ip 10.91.2.35
switch(TAH-elam-insel6)# set outer l4 l4-type 0
switch(TAH-elam-insel6)# set outer l4 dst-port 445
switch(TAH-elam-insel6)# start
Después de generar el tráfico, recupere el resultado:
switch(TAH-elam-insel6)# report
Captura de tráfico inversa (obligatoria para una visibilidad completa)
Para validar la ruta de acceso de retorno, repita la configuración intercambiando las direcciones IP de origen y de destino:
switch# debug platform internal tah elam
switch(TAH-elam)# trigger init
Slot 1: param values: start asic 0, start slice 0, lu-a2d 1, in-select 6, out-select 0
switch(TAH-elam-insel6)# set outer ipv4 dst_ip 10.93.19.8
switch(TAH-elam-insel6)# set outer ipv4 src_ip 10.91.2.35
switch(TAH-elam-insel6)# set outer l4 l4-type 0
switch(TAH-elam-insel6)# set outer l4 dst-port 445
switch(TAH-elam-insel6)# start
Notas operativas
Guía de ELAM ASIC de la escala de nube Cisco Nexus 9000
La validación a nivel de interfaz garantiza que el switch Nexus no introduzca ninguna restricción o anomalía que afecte al tráfico TCP. El objetivo es confirmar que la configuración, el estado operativo y los contadores de hardware son coherentes con el comportamiento esperado para el reenvío del plano de datos de alto rendimiento.
Validación de configuración
switch# show running-config interface ethernet1/1-2 | include access-group
switch#show running-config interface ethernet1/1-2 | include service-policyswitch#show policy-map interface ethernet1/1-2
switch# show policy-map
switch# show class-map
switch# show class-map type network-qos
switch# show policy-map type network-qos
switch#show policy-map system type network-qos
switch# show queuing interface ethernet1/1-2
switch# show policy-map type queuing
switch#show running-config interface ethernet1/1-2
switch#show interface ethernet1/1-2 switchport
switch#show spanning-tree interface ethernet1/1-2
switch# show ip interface ethernet1/1-2
Validación del estado operativo
switch#show interface ethernet1/1-2 | include MTU
switch#show interface ethernet1/1-2 | include speed|duplex
switch#show interface ethernet1/1-2 | include rate|flap
Validación de contadores de errores
switch#clear counters interface all
switch#show interface counters errors non-zero | include Port|Eth1/1|Eth1/2
Validación posterior a la prueba
switch#show interface counters errors non-zero | include Port|Eth1/1|Eth1/2
Garantizar el routing y la estabilidad ARP es fundamental para confirmar que el switch Nexus tiene un alcance de capa 3 uniforme y no presenta problemas de resolución intermitentes que puedan afectar al rendimiento de TCP. La inestabilidad en las entradas de ruteo o en la resolución ARP puede conducir a la pérdida de paquetes, al aumento de la latencia o al bloqueo del tráfico.
Criterios de validación
switch# show ip route 10.93.19.8
switch# show ip route 10.91.2.35
switch# show ip arp detail | include 10.93.19.8
switch# show ip arp detail | include 10.91.2.35
En los switches Cisco Nexus 9000, el reenvío se realiza en el hardware (ASIC) y la CPU no participa en las operaciones normales del plano de datos. Por lo tanto, observar el tráfico TCP de host a host en el plano de control es anormal e indica que los paquetes se están impulsando debido a excepciones o configuraciones erróneas. Una vez que la CPU debe procesar el tráfico, éste queda sujeto a Control Plane Policing, y se espera que se puedan observar caídas si el tráfico excede la velocidad del plano de control permitida.
Método de validación
switch# ethanalyzer local interface inband display-filter "ip.addr==10.93.19.8 and ip.addr==10.91.2.35" limit-capture 0
Comportamiento esperado
Comportamiento inesperado
La latencia de reenvío de paquetes en los switches Nexus 9000 depende del tamaño del paquete, el modo de reenvío y las funciones habilitadas. Las especificaciones de Cisco suelen hacer referencia a la latencia de los paquetes de 64 bytes en el reenvío por conexión directa.
+----------------------+----------------------+-------------------------+-------------------------------+
| Switch Model | ASIC / Architecture | Ports (example config) | Typical Forwarding Latency |
| | | | (64B packet) |
+----------------------+----------------------+-------------------------+-------------------------------+
| Nexus 93180YC-EX | Cloud Scale (EX) | 48x25G + 6x100G | ~1.0 – 1.2 microseconds |
| Nexus 93180YC-FX | Cloud Scale (FX) | 48x25G + 6x100G | ~0.9 – 1.0 microseconds |
| Nexus 93180YC-FX2 | Cloud Scale (FX2) | 48x25G + 6x100G | ~0.8 – 0.9 microseconds |
| Nexus 9364C | Cloud Scale | 64x100G | ~1.0 microsecond |
| Nexus 9336C-FX2 | Cloud Scale (FX2) | 36x100G | ~0.8 microseconds |
| Nexus 93240YC-FX2 | Cloud Scale (FX2) | 48x25G + 12x100G | ~0.8 – 0.9 microseconds |
| Nexus 92300YC | Broadcom Trident II | 48x10/25G + 6x40/100G | ~2 – 3 microseconds |
| Nexus 92160YC-X | Broadcom Tomahawk | 48x25G + 6x100G | ~2 microseconds |
+----------------------+----------------------+-------------------------+-------------------------------+
Las funciones adicionales pueden introducir una latencia incremental:
Sin embargo:
El único escenario realista en el que la latencia aumenta considerablemente es la congestión:
Incluso en estos casos:
Esto permite duplicar el tráfico del plano de datos en el plano de control para la captura de paquetes y la exportación a un archivo .pcapng, lo que permite un análisis detallado en Wireshark.
Configuración
monitor session 1
source interface ethernet1/1 both
source interface ethernet1/2 both
destination interface sup-eth0
no shut
Capturar ejecución
switch# ethanalyzer local interface inband mirror capture-filter "tcp port 445" limit-capture 0 write bootflash:tcp_capture.pcapng
Consideraciones técnicas
| Método | Ventaja | Limitación |
|---|---|---|
| TRAMO |
Precisa, sin encapsulación |
Requiere conexión física. |
| ERSPAN |
Capacidad de captura remota |
Susceptible a la congestión de la red. |
Para garantizar que las capturas de SPAN a CPU sean confiables, es necesario validar que el plano de control no está descartando paquetes reflejados debido a la limitación de velocidad.
Comando de validación
switch(config)# show hardware rate-limiter | i Allowed|span
Allowed, Dropped & Total: aggregated bytes since last clear counters
R-L Class Config Allowed Dropped Total
span 50 0 0 0 <<<
span-egress disabled 0 0 0
Metodología de validación
Interpretación
Si se observan caídas, el método de captura debe cambiarse a SPAN o ERSPAN.
Las pruebas de ICMP proporcionan una validación de línea base de la integridad del plano de datos antes de realizar análisis de TCP complejos. Debido a que el ICMP no tiene estado y es más simple, permite una detección rápida de pérdida de paquetes, duplicación o inconsistencias de trayectoria.
Comportamiento esperado en la captura de SPAN
Esto confirma el reenvío correcto y la ausencia de pérdida de paquetes en el plano de datos.
Comportamiento anormal
Si el tráfico ICMP se reenvía constantemente sin pérdidas, existe una alta probabilidad de que el tráfico TCP también se reenvíe correctamente en la Capa 2/3.
Cuando el tráfico se captura usando SPAN a CPU (o SPAN/ERSPAN), cada paquete se puede observar dos veces: una vez en el ingreso y una vez en el egreso. Esta duplicación se puede utilizar para estimar la latencia de reenvío introducida por el switch Nexus calculando la diferencia de tiempo entre ambas instancias del mismo paquete.
En la práctica, esta latencia se puede medir utilizando el tráfico ICMP capturado anteriormente comparando el delta de tiempo entre los paquetes duplicados de solicitud de eco y respuesta de eco. Esto proporciona una línea de base sencilla y eficaz para el rendimiento de reenvío del switch. Si se requiere un análisis más profundo, se puede aplicar la misma metodología al tráfico TCP capturando el flujo y midiendo la diferencia de tiempo entre los paquetes TCP duplicados.
Metodología
Configuración de Wireshark
View > Time Display Format > Seconds Since Previous Displayed Packet
Right-click on "Time Delta from Previous Displayed Packet" → Apply as Column
ip.addr==10.93.19.8 and ip.addr==10.91.2.35 and tcp
Right-click packet → Follow → TCP Stream
Interpretación
Esta sección proporciona una metodología detallada para analizar una captura de paquetes TCP en Wireshark, incluida la configuración del perfil, a través del caso hipotético descrito anteriormente. Las imágenes mostradas fueron tomadas directamente desde Wireshark. A modo de recordatorio, la situación es la siguiente:
Un usuario ha identificado que el proceso de copia de seguridad de un conjunto de datos de aplicación de aproximadamente 6,5 TB, que anteriormente se completaba en unas 9 horas, ahora tarda casi 21 horas. El único dispositivo de red accesible es un switch Cisco Nexus 9300 conectado al servidor de origen (10.93.19.8). La MTU configurada en la interfaz del switch es de 9000 bytes (tramas jumbo), mientras que la MTU en el servidor es desconocida. Hay disponible una captura de paquetes del servidor de origen y todos los pasos de validación de Nexus anteriores ya se han completado sin que se detecten anomalías.
Principales observaciones y limitaciones
En Wireshark, puede crear perfiles personalizados adaptados al tipo específico de análisis que desee realizar.
Descripción de columna
Es obligatorio capturar el protocolo de enlace de tres vías TCP porque contiene parámetros críticos como MSS, Window Scale y SACK que definen cómo se comporta la sesión.
Sin esta información, cualquier análisis de TCP es incompleto y puede llevar a conclusiones incorrectas sobre el rendimiento o la causa raíz.

Desde la captura de paquetes:
El RTT inicial (iRTT) se calcula como:
Este valor se deriva de:
La mayor parte de la latencia (~94%) se encuentra en la ruta de reenvío (cliente → servidor → cliente), mientras que el tiempo de respuesta del origen es mínimo, lo que indica que no hay retraso de la CPU o de la aplicación en el cliente.
El puerto 445 corresponde al Bloque de mensajes de Microsoft Server (SMB), que se utiliza habitualmente para compartir archivos, unidades de red y servicios de autenticación de Windows. Este protocolo es sensible tanto a la latencia como al rendimiento, por lo que depende en gran medida de la eficacia de TCP y de la estabilidad de la red.
La ventana TCP representa la cantidad de datos que se pueden enviar antes de esperar la confirmación. En este caso, el origen es ligeramente más restrictivo que el destino. Estos valores son relativamente pequeños para los entornos modernos y pueden limitar el rendimiento, especialmente a medida que aumenta el RTT.
El rendimiento teórico máximo se puede calcular utilizando:
Rendimiento = Tamaño de la ventana TCP/RTT
Sustitución de los valores observados:
Rendimiento ≈ 64 240 / 0,000798 ≈ 80,5 MB/s (~644 Mbps)
Esto representa el rendimiento del límite superior suponiendo que:
Con el rendimiento actual de 644 Mbps, la transferencia de un archivo de 6,5 TB tarda aproximadamente 23,5 horas, lo que coincide con la degradación observada. Para lograr un intervalo de transferencia de 9 horas, el rendimiento debe aumentar hasta aproximadamente 1,68 Gbps, lo que requiere una ventana TCP más grande (~2,7 veces más) o un RTT significativamente inferior (~291 µs).
Con las condiciones actuales (ventana de 64 KB y ~798 µs RTT), no es posible alcanzar el objetivo de 9 horas, porque el rendimiento de TCP está limitado por el producto de retraso de ancho de banda. Sin aumentar el tamaño de la ventana o reducir la latencia, el protocolo no puede utilizar un ancho de banda disponible más alto, lo que hace que el objetivo sea inalcanzable.
| Situación | Rendimiento de procesamiento | Tiempo de transferencia estimado (6,5 TB) | Ventana TCP requerida | RTT requerido |
|---|---|---|---|---|
| Estado actual |
644 Mbps (~80,5 MB/s) |
~23,5 horas |
64 KB |
798 µs |
| Objetivo (9 horas) |
~1683 Mbps (~210 MB/s) |
9 horas |
~172 KB |
~291 µs |
Esto funcionaba anteriormente, lo que indica que se ha producido un cambio en la red, la aplicación, el origen o el destino. Es importante señalar que, únicamente sobre la base de este análisis inicial, ya se puede llegar a una conclusión significativa: con el tamaño actual de la ventana TCP y las condiciones de RTT, no es posible alcanzar el objetivo de 9 horas.
Las tablas muestran una comparación de cómo varía el rendimiento a medida que el tamaño de la ventana RTT y TCP aumenta o disminuye.
Impacto de RTT en el rendimiento (tamaño de ventana fijo = 64 240 bytes)
| RTT | Rendimiento (MB/s) | Rendimiento (Mbps) |
|---|---|---|
| 200 µs (0,0002 s) |
~321 MB/s |
~2.568 Mbps |
| 798 µs (0,000798 s) |
~80,5 MB/s |
~644 Mbps |
| 2 ms (0,002 s) |
~32,1 MB/s |
~257 Mbps |
| 10 ms (0,01 s) |
~6,4 MB/s |
~51 Mbps |
Impacto en el tamaño de la ventana TCP (RTT fijo = 798 µs)
| Tamaño de la ventana TCP | Rendimiento (MB/s) | Rendimiento (Mbps) |
|---|---|---|
| 16 KB (16 384 B) |
~20,5 MB/s |
~164 Mbps |
| 64 KB (64 240 B) |
~80,5 MB/s |
~644 Mbps |
| 256 KB (262.144 B) |
~328 MB/s |
~2624 Mbps |
| 1 MB (1.048.576 KB) |
~1314 MB/s |
~10,5 Gbps |
Interpretación técnica
Esto demuestra que el tamaño de la ventana RTT y TCP son factores críticos en el rendimiento TCP y deben analizarse conjuntamente al resolver problemas de rendimiento.
Un encabezado IP de 20 bytes indica que no hay opciones IP presentes. El encabezado TCP de 32 bytes confirma que se están usando las opciones TCP, agregando 12 bytes más allá del encabezado base. Estas opciones suelen incluir MSS, Windows Scale y SACK Permitted.
La confirmación selectiva (SACK) está habilitada en ambos terminales. Esto no se ve en la imagen. SACK permite al receptor confirmar bloques de datos no contiguos, informando al remitente exactamente qué segmentos se recibieron con éxito.
Por ejemplo, si se reciben los segmentos 1000-2000 y 3000-4000 pero falta 2000-3000, el receptor puede indicarlo explícitamente. Sin SACK, el remitente retransmitiría todos los datos después de la brecha; con SACK, solo se retransmite la parte que falta. Esto mejora significativamente el rendimiento en entornos con pérdida de paquetes.
Análisis de paquete 1 (SYN)
Wireshark normaliza el número de secuencia a cero para facilitar la lectura, aunque en la práctica es un valor aleatorio grande. Se espera la ausencia de carga útil durante el establecimiento de la conexión. El valor MSS de 1460 bytes indica una MTU de 1500 bytes (encabezado IP de 20 bytes + encabezado TCP de 20 bytes). Un TTL de 128 puede ser un host basado en Windows, y ver este valor en la captura indica que la captura probablemente se tomó en o muy cerca del origen a través de la Capa 2.
Análisis de paquete 2 (SYN-ACK)
El valor ACK es 1 porque el indicador SYN consume un número de secuencia, incluso cuando no hay carga útil presente. Por lo tanto, ACK = SEQ + 1.
El TTL observado de 59 sugiere un TTL inicial de 64, lo que significa que el paquete atravesó aproximadamente 5 saltos de ruteo (64 − 59 = 5). Cada salto ruteado disminuye el TTL en uno.
Riesgo de fragmentación e impacto en la red
La presencia de aproximadamente cinco saltos de ruteo introduce riesgos potenciales de rendimiento, especialmente relacionados con las discordancias y fragmentación de MTU.
Si cualquier link intermedio tiene una MTU menor que el tamaño del paquete original, puede ocurrir la fragmentación. Esto conlleva varias consecuencias:
Teniendo en cuenta estos factores, es fundamental garantizar una MTU uniforme a lo largo de la ruta o implementar una sujeción MSS cuando sea necesario.
Cuando ACK RTT es mayor que iRTT, indica que la latencia ha aumentado en comparación con la línea de base establecida durante el intercambio de señales TCP.
Esto significa que la red o los terminales están introduciendo un retraso adicional durante la sesión, debido normalmente a:
Si esta condición persiste durante la sesión TCP, conduce a:
En Wireshark, es posible visualizar la frecuencia con que ocurre la condición ACK RTT > iRTT mediante la función de gráficos de E/S en: Estadísticas → Gráficos de E/S, aplicación del filtro de visualización (tcp.analysis.ack_rtt > tcp.analysis.initial_rtt), selección del estilo de impulso, configuración del eje Y en paquetes y uso de un intervalo de 50 microsegundos.
En el gráfico, los impulsos morados representan el número de paquetes que cumplen esta condición dentro de cada intervalo de 50 microsegundos. Como se ha observado, esta condición persiste durante toda la captura de paquetes, lo que indica que la latencia durante la sesión es constantemente más alta que la línea de base inicial. Este comportamiento sugiere claramente una degradación del rendimiento sostenida en lugar de una condición transitoria, lo que refuerza la necesidad de investigar fuentes potenciales como la congestión, el almacenamiento en búfer o los retrasos en el procesamiento de terminales a través de la ruta de extremo a extremo.

También es importante determinar por cuánto tiempo se excede el iRTT, no solo con qué frecuencia. Aunque Wireshark no permite directamente la resta entre campos, se puede lograr una comparación visual utilizando gráficos de E/S:
En esta visualización, el gráfico morado representa la condición ACK RTT > iRTT, que está presente consistentemente a lo largo de toda la sesión TCP. Los datos muestran una inflación de latencia sostenida, con picos múltiples que alcanzan los 11 milisegundos y un pico máximo de más de 100 milisegundos, lo que representa de 11x a 100x el iRTT de línea de base.
Este comportamiento confirma que el aumento de latencia no es transitorio, sino persistente, lo que indica un problema sistémico que afecta a la sesión a lo largo del tiempo. Esta desviación sostenida sugiere factores como la congestión de la red, el almacenamiento en búfer (bufferbloat) o los retrasos en el procesamiento de los terminales.

Esta sección evalúa la confiabilidad de TCP analizando las retransmisiones a lo largo del tiempo, permitiendo la validación de si la pérdida de paquetes está contribuyendo a la degradación del rendimiento.
El gráfico muestra la distribución de las retransmisiones TCP a lo largo del tiempo. Se observaron un total de 42 retransmisiones, que representaban solo el 0,00125% del tráfico total.
Este nivel de retransmisiones es insignificante e indica claramente que la pérdida de paquetes no es un factor que contribuya en esta situación.
Configuración de Wireshark (retransmisiones TCP)
Statistics → I/O Graphs
tcp.analysis.retransmission and !tcp.analysis.spurious_retransmission
El gráfico muestra el número de retransmisiones falsas de TCP en intervalos de 1 segundo generadas por el origen 10.93.19.8.
En Wireshark, una retransmisión espuria de TCP indica que un host retransmitió un segmento que no se perdió realmente. El paquete original llegó correctamente al receptor, pero el remitente asumió incorrectamente la pérdida debido a una estimación inexacta del tiempo. Este comportamiento no indica una pérdida real de paquetes, sino una lógica de retransmisión ineficiente en el remitente.
En esta captura:
Esto confirma que el comportamiento de retransmisión es controlado enteramente por la pila TCP de origen, no por la red.
El número total de retransmisiones falsas observadas es de 1112, lo que representa el 0,0332% del tráfico total capturado.
Configuración de Wireshark (retransmisiones falsas de TCP)
Statistics → I/O Graphs
tcp.analysis.spurious_retransmission and ip.src==10.93.19.8
Interpretación técnica
Este análisis refuerza aún más que el problema no está relacionado con la fiabilidad de la red, sino con el comportamiento de TCP, la latencia o el rendimiento de los terminales.

El gráfico muestra el rendimiento efectivo, calculado en función de la carga útil de TCP (datos reales transferidos) en megabits por segundo. El rendimiento observado oscila principalmente entre 600 Mbps y 800 Mbps, lo que indica que, aunque la red transfiere datos de forma activa, no está alcanzando un mayor potencial de ancho de banda.
Configuración De Wireshark (Rendimiento Eficaz)
Statistics → TCP Streams Graphs → Throughout

Interpretación técnica
El gráfico resalta un comportamiento crítico en la sesión TCP al comparar la capacidad del receptor frente a los datos reales en tránsito (bytes en vuelo).

Los datos observados en vuelo alcanzan picos de aproximadamente 1 MB, con picos adicionales de alrededor de 8 KB y 5 KB, pero se concentran principalmente entre 1 KB y 250 KB.
Esto indica que aunque el receptor es capaz de manejar grandes volúmenes de datos, el remitente no está utilizando consistentemente la ventana disponible.
Configuración de Wireshark (datos en vuelo frente a ventana)
Statistics → TCP Streams Graphs → Throughout
Interpretación técnica
El análisis del tamaño de la carga útil de TCP comparándolo con MSS a lo largo del tiempo ayuda a determinar si el remitente está utilizando eficientemente cada segmento de TCP. Este análisis se realiza desde la perspectiva de la dirección IP de origen (10.93.19.8).
En Wireshark, los gráficos se configuran de la siguiente manera:
Del análisis:

Este análisis demuestra que la identificación de la causa raíz de los problemas de rendimiento de TCP requiere un enfoque integral, en lugar de asumir que la red es la principal fuente de degradación.
Se llevó a cabo una validación exhaustiva en el switch Cisco Nexus 9300, incluidos los contadores de interfaz, las políticas de QoS, el routing y la estabilidad ARP, la verificación de punt de CPU, la captura de paquetes basada en SPAN y la validación de reenvío de nivel ASIC mediante ELAM. Todos los resultados confirmaron consistentemente que el switch estaba funcionando dentro de los parámetros esperados:
Además, el análisis de TCP reveló:
La degradación del rendimiento se debe a que el servidor de origen funciona con MTU 1500 en un entorno con capacidad Jumbo, lo que impide un uso eficiente de la capacidad de red disponible.
Aumente la MTU en el servidor de origen de 1500 a 9000 bytes para alinearlo con el destino y la infraestructura de red. Las ventajas:
Una conclusión clave de este análisis es la importancia de evitar conclusiones prematuras a la hora de solucionar problemas de rendimiento de red. Si bien es común atribuir inicialmente problemas a la red, este caso demuestra claramente que la red funcionaba correctamente a lo largo de toda la ruta del plano de datos. Solo mediante un análisis profundo de TCP desde las perspectivas de origen y de destino (incluidos los parámetros de entrada en contacto, el comportamiento de RTT, la utilización de la ventana, las retransmisiones y la eficiencia de la carga útil) fue posible identificar con precisión el verdadero cuello de botella.
Dedicar tiempo a analizar detalladamente el comportamiento de TCP evita errores de diagnóstico, reduce los cambios innecesarios en la red y garantiza que los esfuerzos de remediación se dirijan a la causa real.
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
2.0 |
07-May-2026
|
Título actualizado por solicitud de autor. |
1.0 |
06-May-2026
|
Versión inicial |