tcpdump affiche des paquets de 64 Ko : offload et point de capture

Une capture sur un hôte peut montrer un paquet de 64 Ko sur une interface dont le MTU est de 1420, et la conclusion évidente est que le tunnel a ignoré sa limite de taille. Cette conclusion est généralement fausse. Les points de capture sur l’hôte se situent à l’intérieur du chemin de traitement, où la segmentation, l’agrégation et le calcul de somme de contrôle peuvent ne pas encore avoir eu lieu. Lisez la position de l’observateur avant de lire la taille du paquet.

Là où vous capturez change ce que vous voyez

L’offload de transmission permet à la pile de remettre une grande unité à la carte réseau, qui la découpe ensuite en morceaux à la taille du câble. L’agrégation en réception fait l’inverse à l’entrée, en joignant des segments avant qu’un observateur côté hôte ne les voie. Une capture enregistre donc la vue interne de l’hôte à cet endroit, pas nécessairement les trames sur le lien. Les deux mécanismes dépendent de la carte et du chemin.

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

Capturez à un second point, idéalement un récepteur indépendant ou un miroir, avant de traiter la taille comme un défaut. Si la grande unité n’apparaît que sur l’hôte émetteur, le câble ne l’a peut-être jamais transportée. Deux points d’observation valent mieux qu’un seul fichier, surtout lorsque la question est ce qui a réellement quitté la machine.

Séparez l’interface interne et l’interface externe

Un tunnel ajoute sa propre interface, et les vues externe et interne diffèrent par l’encapsulation et par le traitement. Une capture sur l’interface du tunnel montre le paquet interne ; une capture sur la carte physique montre l’externe. La taille, les adresses et l’état de la somme de contrôle peuvent différer entre les deux pour des raisons sans rapport avec un défaut.

Notez quelle interface a produit chaque fichier. Une taille vue sur l’interface du tunnel décrit le paquet interne, pas la trame que la carte a fini par envoyer. Les mélanger dans une même analyse, c’est ainsi qu’une différence d’encapsulation normale devient un mystère.

Un avertissement de somme de contrôle est aussi positionnel

Une capture côté émission peut montrer un champ de somme de contrôle avant que le matériel ne le remplisse, ce qui produit un avertissement qu’aucun récepteur ne verrait jamais. C’est une preuve différente de celle d’un hôte distant qui rejette un paquet endommagé. La direction et le point de capture décident laquelle des deux vous avez.

Lorsqu’un transfert réel échoue, comparez les observations chez un récepteur ou à un autre point du chemin. Conservez la direction, l’interface et la couche d’encapsulation avec l’enregistrement, car une capture d’écran sans elles ne pourra pas être interprétée plus tard.

Ne désactivez l’offload que comme test contrôlé

Désactiver l’offload modifie les performances et le traitement des paquets, ce n’est donc pas la première réaction à un affichage de taille étrange. Si vous le testez, changez un seul réglage et relevez d’abord la référence. Une exécution qui modifie aussi le MTU, les règles de pare-feu et le profil client ne peut pas attribuer le résultat à l’offload. Rétablissez le réglage ensuite.

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

Un vrai blocage de gros transfert est une question distincte, celle du MTU du chemin et du retour que reçoit l’application. Une unité agrégée par l’hôte ne prouve ni ne réfute une limite de taille en aval, et un faible pourcentage de CPU n’identifie pas l’offload comme cause.

Le résultat utile est un point de capture expliqué, plus une observation applicative reproductible. Une fois les deux séparés, un changement de MTU peut viser une contrainte réelle plutôt que la forme d’un tampon interne.