Capturar nun host pode mostrar un paquete de 64 KB nunha interface cunha MTU de 1420, e a conclusión obvia é que o túnel ignorou o seu límite de tamaño. Esa conclusión adoita ser errónea. Os puntos de captura no host están dentro da ruta de procesamento, onde a segmentación, a agregación e o traballo de checksum poden non ter ocorrido aínda. Lea a posición do observador antes de ler o tamaño do paquete.

Onde captura cambia o que ve

O offload de transmisión permite que a pila entregue unha unidade grande ao dispositivo de rede, que despois a corta en pezas do tamaño do cable. A agregación de recepción fai o contrario na entrada, unindo segmentos antes de que un observador do lado do host os vexa. Por tanto, unha captura rexistra a visión interna do host nese punto, non necesariamente as tramas da ligazón. Ambos mecanismos dependen do dispositivo e da ruta.

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

Capture nun segundo punto, idealmente un receptor independente ou un espello, antes de tratar o tamaño como unha avaría. Se a unidade grande só aparece no host emisor, pode que o cable nunca a transportase. Dous puntos de observación son máis fortes ca un só ficheiro, sobre todo cando a pregunta é que saíu realmente da máquina.

Separe as interfaces interna e externa

Un túnel engade a súa propia interface, e as visións externa e interna difiren en encapsulación e en procesamento. Unha captura no dispositivo do túnel mostra o paquete interno; unha captura no adaptador físico mostra o externo. O tamaño, os enderezos e o estado do checksum poden diferir entre eles por motivos que non teñen nada que ver cunha avaría.

Rexistre que interface produciu cada ficheiro. Un tamaño visto no dispositivo do túnel describe o paquete interno, non a trama que o adaptador acabou enviando. Mesturalos nunha soa análise é como unha diferenza normal de encapsulación se converte nun misterio.

O aviso de checksum tamén é posicional

Unha captura do lado de transmisión pode mostrar un campo de checksum antes de que o hardware o encha, o que produce un aviso que ningún receptor vería xamais. É unha evidencia distinta da dun host remoto que rexeita un paquete danado. A dirección e o punto de captura deciden cal das dúas ten.

Cando falla unha transferencia real, compare observacións nun receptor ou noutro punto da ruta. Garde a dirección, a interface e a capa de encapsulación co rexistro, porque unha captura de pantalla sen elas non se pode interpretar despois.

Desactive o offload só como proba controlada

Desactivar o offload cambia o rendemento e o procesamento de paquetes, así que non é a primeira resposta ante unha visualización estraña do tamaño. Se o proba, cambie un só axuste e rexistre primeiro a liña base. Unha execución que tamén cambia a MTU, as regras da devasa e o perfil do cliente non pode atribuír o resultado ao offload. Restaure o axuste despois.

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

Un bloqueo real dunha transferencia grande é unha cuestión aparte sobre a MTU da ruta e a realimentación que recibe a aplicación. A unidade agregada dun host nin demostra nin refuta un límite de tamaño augas abaixo, e unha porcentaxe baixa de CPU non identifica o offload como a causa.

O resultado útil é un punto de captura explicado máis unha observación reproducible da aplicación. Con iso separado, un cambio de MTU pode apuntar a unha restrición real en lugar da forma dun búfer interno.

Artigos relacionados