tcpdump mostra pacchetti da 64 KB: offload e punto di cattura

Una cattura su un host può mostrare un pacchetto da 64 KB su un’interfaccia con MTU 1420, e la conclusione ovvia è che il tunnel ha ignorato il suo limite di dimensione. Quella conclusione di solito è sbagliata. I punti di cattura sull’host si trovano dentro il percorso di elaborazione, dove segmentazione, aggregazione e lavoro di checksum possono non essere ancora avvenuti. Leggete la posizione dell’osservatore prima di leggere la dimensione del pacchetto.

Dove catturate cambia ciò che vedete

L’offload di trasmissione consente allo stack di consegnare un’unità grande al dispositivo di rete, che la taglia poi in pezzi della dimensione del cavo. L’aggregazione in ricezione fa il contrario in ingresso, unendo segmenti prima che un osservatore lato host li veda. Una cattura registra quindi la vista interna dell’host in quel punto, non necessariamente i frame sul collegamento. Entrambi i meccanismi dipendono dal dispositivo e dal percorso.

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

Catturate in un secondo punto, idealmente un ricevitore indipendente o uno specchio, prima di trattare la dimensione come un guasto. Se l’unità grande compare solo sull’host mittente, il cavo potrebbe non averla mai trasportata. Due punti di osservazione sono più forti di un solo file, soprattutto quando la domanda è che cosa ha realmente lasciato la macchina.

Separate l’interfaccia interna ed esterna

Un tunnel aggiunge la propria interfaccia, e le viste esterna e interna differiscono per incapsulamento ed elaborazione. Una cattura sul dispositivo del tunnel mostra il pacchetto interno; una cattura sull’adattatore fisico mostra quello esterno. Dimensione, indirizzi e stato del checksum possono differire tra i due per motivi che non hanno nulla a che vedere con un guasto.

Registrate quale interfaccia ha prodotto ciascun file. Una dimensione vista sul dispositivo del tunnel descrive il pacchetto interno, non il frame che l’adattatore ha finito per inviare. Mescolarli in un’unica analisi è il modo in cui una normale differenza di incapsulamento diventa un mistero.

Anche un avviso di checksum è posizionale

Una cattura lato trasmissione può mostrare un campo di checksum prima che l’hardware lo riempia, il che produce un avviso che nessun ricevitore vedrebbe mai. È una prova diversa da quella di un host remoto che rifiuta un pacchetto danneggiato. La direzione e il punto di cattura decidono quale delle due avete.

Quando un trasferimento reale fallisce, confrontate le osservazioni su un ricevitore o in un altro punto del percorso. Conservate direzione, interfaccia e livello di incapsulamento insieme alla registrazione, perché uno screenshot senza di essi non può essere interpretato in seguito.

Disattivate l’offload solo come test controllato

Disattivare l’offload cambia prestazioni ed elaborazione dei pacchetti, quindi non è la prima risposta a una visualizzazione strana della dimensione. Se lo provate, cambiate un’impostazione e registrate prima la linea di base. Un’esecuzione che cambia anche MTU, regole del firewall e profilo del client non può attribuire il risultato all’offload. Ripristinate l’impostazione dopo.

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

Un vero blocco di un trasferimento grande è una questione separata sull’MTU del percorso e sul riscontro che riceve l’applicazione. L’unità aggregata di un host non dimostra né confuta un limite di dimensione a valle, e una bassa percentuale di CPU non identifica l’offload come causa.

Il risultato utile è un punto di cattura spiegato più un’osservazione riproducibile dell’applicazione. Con questi separati, una modifica dell’MTU può puntare a un vincolo reale invece che alla forma di un buffer interno.