tcpdump muestra paquetes de 64 KB: offload y punto de captura

Capturar en un host puede mostrar un paquete de 64 KB en una interfaz con MTU 1420, y la conclusión obvia es que el túnel ignoró su límite de tamaño. Esa conclusión suele ser errónea. Los puntos de captura en el host están dentro de la ruta de procesamiento, donde la segmentación, la agregación y el trabajo de checksum pueden no haber ocurrido todavía. Lea la posición del observador antes de leer el tamaño del paquete.

Dónde captura cambia lo que ve

El offload de transmisión permite que la pila entregue una unidad grande al dispositivo de red, que después la corta en piezas del tamaño del cable. La agregación de recepción hace lo contrario en la entrada, uniendo segmentos antes de que un observador del lado del host los vea. Por tanto, una captura registra la visión interna del host en ese punto, no necesariamente las tramas del enlace. Ambos mecanismos dependen del dispositivo y de la ruta.

ethtool -k eth0 | grep -E 'tso|gso|gro'

Capture en un segundo punto, idealmente un receptor independiente o un espejo, antes de tratar el tamaño como una avería. Si la unidad grande solo aparece en el host emisor, puede que el cable nunca la haya transportado. Dos puntos de observación son más fuertes que un solo archivo, sobre todo cuando la pregunta es qué salió realmente de la máquina.

Separe las interfaces interna y externa

Un túnel añade su propia interfaz, y las vistas externa e interna difieren en encapsulación y en procesamiento. Una captura en el dispositivo del túnel muestra el paquete interno; una captura en el adaptador físico muestra el externo. El tamaño, las direcciones y el estado del checksum pueden diferir entre ellos por motivos que no tienen nada que ver con una avería.

Registre qué interfaz produjo cada archivo. Un tamaño visto en el dispositivo del túnel describe el paquete interno, no la trama que el adaptador acabó enviando. Mezclarlos en un solo análisis es como una diferencia normal de encapsulación se convierte en un misterio.

El aviso de checksum también es posicional

Una captura del lado de transmisión puede mostrar un campo de checksum antes de que el hardware lo rellene, lo que produce un aviso que ningún receptor vería jamás. Es una evidencia distinta de la de un host remoto que rechaza un paquete dañado. La dirección y el punto de captura deciden cuál de las dos tiene.

Cuando falla una transferencia real, compare observaciones en un receptor o en otro punto de la ruta. Guarde la dirección, la interfaz y la capa de encapsulación con el registro, porque una captura de pantalla sin ellos no se puede interpretar después.

Desactive el offload solo como prueba controlada

Desactivar el offload cambia el rendimiento y el procesamiento de paquetes, así que no es la primera respuesta ante una visualización extraña del tamaño. Si lo prueba, cambie un solo ajuste y registre primero la línea base. Una ejecución que también cambia la MTU, las reglas del cortafuegos y el perfil del cliente no puede atribuir el resultado al offload. Restaure el ajuste después.

ethtool -K eth0 tso off gro off
ping -M do -s 1400 example.com

Un atasco real de una transferencia grande es una cuestión aparte sobre la MTU de la ruta y la realimentación que recibe la aplicación. La unidad agregada de un host ni demuestra ni refuta un límite de tamaño aguas abajo, y un porcentaje bajo de CPU no identifica el offload como la causa.

El resultado útil es un punto de captura explicado más una observación reproducible de la aplicación. Con eso separado, un cambio de MTU puede apuntar a una restricción real en lugar de a la forma de un búfer interno.