tcpdump mostra pacotes de 64 KB: offload e ponto de captura

Capturar num host pode mostrar um pacote de 64 KB numa interface com MTU 1420, e a conclusão óbvia é que o túnel ignorou o seu limite de tamanho. Essa conclusão costuma estar errada. Os pontos de captura no host ficam dentro do caminho de processamento, onde a segmentação, a agregação e o trabalho de checksum podem ainda não ter ocorrido. Leia a posição do observador antes de ler o tamanho do pacote.

Onde captura muda o que vê

O offload de transmissão permite que a pilha entregue uma unidade grande ao dispositivo de rede, que depois a corta em pedaços do tamanho do cabo. A agregação de receção faz o contrário na entrada, juntando segmentos antes de um observador do lado do host os ver. Uma captura regista, portanto, a visão interna do host naquele ponto, não necessariamente as tramas no link. Ambos os mecanismos dependem do dispositivo e do caminho.

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

Capture num segundo ponto, idealmente um recetor independente ou um espelho, antes de tratar o tamanho como uma falha. Se a unidade grande só aparece no host emissor, o cabo pode nunca a ter transportado. Dois pontos de observação são mais fortes do que um único ficheiro, sobretudo quando a pergunta é o que saiu realmente da máquina.

Separe as interfaces interna e externa

Um túnel acrescenta a sua própria interface, e as vistas externa e interna diferem em encapsulamento e em processamento. Uma captura no dispositivo do túnel mostra o pacote interno; uma captura no adaptador físico mostra o externo. O tamanho, os endereços e o estado do checksum podem diferir entre eles por razões que nada têm a ver com uma falha.

Registe qual interface produziu cada ficheiro. Um tamanho visto no dispositivo do túnel descreve o pacote interno, não a trama que o adaptador acabou por enviar. Misturá-los numa só análise é como uma diferença normal de encapsulamento se torna um mistério.

O aviso de checksum também é posicional

Uma captura do lado da transmissão pode mostrar um campo de checksum antes de o hardware o preencher, o que produz um aviso que nenhum recetor veria jamais. É uma evidência diferente da de um host remoto que rejeita um pacote danificado. A direção e o ponto de captura decidem qual das duas tem.

Quando uma transferência real falha, compare observações num recetor ou noutro ponto do caminho. Guarde a direção, a interface e a camada de encapsulamento com o registo, porque uma captura de ecrã sem elas não pode ser interpretada mais tarde.

Desative o offload apenas como teste controlado

Desativar o offload altera o desempenho e o processamento de pacotes, por isso não é a primeira resposta a uma exibição estranha do tamanho. Se testar, altere uma única definição e registe primeiro a linha de base. Uma execução que também altera a MTU, as regras da firewall e o perfil do cliente não pode atribuir o resultado ao offload. Restaure a definição depois.

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

Um bloqueio real de uma transferência grande é uma questão separada sobre a MTU do caminho e o retorno que a aplicação recebe. A unidade agregada de um host nem prova nem refuta um limite de tamanho a jusante, e uma percentagem baixa de CPU não identifica o offload como causa.

O resultado útil é um ponto de captura explicado mais uma observação reproduzível da aplicação. Com isso separado, uma alteração de MTU pode apontar para uma restrição real em vez da forma de um buffer interno.